On Friday 02 September 2005 02:37, bulia byak wrote:

Well, as you understand, we must have some minimum limit to zoom, and no matter how far it is, there will be documents so large that you can't zoom out far enough. So, what do you propose? Unlimited zoom-out is impossible. We can stretch it to accommodate this particular file, but there will always be still larger ones.

Well, on a purely technical level... bignums would would cover this, wouldn't it?

http://en.wikipedia.org/wiki/Bignum

I'm sure the performance would suck, though. I'm not advocating this as a solution :)

On 9/2/05, bulia byak <buliabyak@...400...> wrote:

...

Can't "Export bitmap" be turned into "Export", offering a choice of bitmaps, and remembering the chosen filename?

"Export bitmap" has a lot of bitmap-specific options, so I don't think we can combine it easily with vector export. However I do agree that "Save as" is not the most logical place to look up for EPS export. Perhaps we should separate that into an "Export vector" command.

I hesitate to tell you how many times this was discussed :)

Okay, here is a small review of what I have on my Windows PC at work right now.

In Macromedia MX11 "File" menu contains:

Save Save As... (EPS and Macromedia file types only) Import... (any file types, both bitmap and vector) Export... (any file types, both bitmap and vector) Export Again (definitely useful) Publish as HTML... Collect for Output...

In Xara X1:

Save Save As... (only Xara X file type) Import (any file types, both bitmap and vector) Import from Web (asks for URL) Export... (any file types, both bitmap and vector) Export Animated GIF... Export Image In Slices...

In Corel DRAW v11:

Save... (lots of vector file types) Save As... (same vector file types as above) Import... (bitmap, vector, text and spreadsheet formats available) Export... (bitmap, vector, text and spreadsheet formats available, "websafe filenames" checkbox, "selected only" checkbox) Prepare For Service Bureau... (Same as "collect for output", I guess) Publish To The Web (with "HTML" and "Flash embedded in HTML" submenu items) Publish To PDF...

My Adobe Illustrator CS2 copy is at home, so I can't help you here right now.

Alexandre

On 9/2/05, bulia byak <buliabyak@...400...> wrote:

On 9/2/05, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:

...

In Macromedia MX11 "File" menu contains: Export... (any file types, both bitmap and vector)

This and other examples do not convince me.

I'm not trying to convince you :)

All I'm trying to say is that "Save As" should save to only those file formats which can be edited by Inkscape as good as its native SVG, which is proved by other common applications like Corel DRAW, Xara X and others.

An ideal _bitmap_ export dialog must:

• stay open as you work

• track your selection

• have the filename field which fills itself in as you change selection

• have fields for area and w/h/resolution which also fill itself in as

you change selection

The current one has all this, and it's by far the most convenient among all I've used anywhere (even though it does not have a preview and a few other things).

Sure, and I find it useful for my work! :)

NONE of this is necessary for vector export;

And here I disagree. And I'm not the only one. To give you idea:

http://sourceforge.net/tracker/index.php?func=detail&aid=1104601&gro... http://sourceforge.net/tracker/index.php?func=detail&aid=1067897&gro...

I'm not trying to tell you that this has high priority, but at least this is requested by users and needs to be addressed sometime in the future.

Again, current implementation of exporting to other vector formats is *very* confusing. It' not expected from an application to save *AS* something in an uneditable file format.

...

Export Again (definitely useful)

Surely we have that capability for bitmap exports - just leave the dialog on and click Export again and again.

Yes, and I wasn't insisting that we don't already ahve it :)

Alexandre

On 9/3/05, bulia byak <buliabyak@...400...> wrote:

Just please don't break "Export bitmap" and I won't complain :)

Never! :)

Alexandre

On Fri, Sep 02, 2005 at 07:09:32PM +0100, Alan Horkan wrote:

...

Publish as HTML...

With Gnome VFS and or WebDAV or some other backend properly setup I imagine we could have a useful Publish function in Inkscape too.

Well, we have Gnome VFS as a dependency currently, so this is entirely doable. It just requires someone to design how this should work. I think the coding would be pretty straightforward, it's just that there's a LOT of different permutations that'd need to be thought out.

Bryce

Gavin Band wrote:

(and on my machine, the "Height" part seems to be greyed out).

Not being able to change the height on export ALWAYS gets in my way. Is there a reason for it? or should I make changing that my next project?

Aaron Spike

bulia byak wrote:

On 9/2/05, aaron@...749... <aaron@...749...> wrote:

...

Not being able to change the height on export ALWAYS gets in my way. Is there a reason for it? or should I make changing that my next project?

Changing height would mean exporting with different aspect ration than what you see on screen, i.e. potential surprises without a preview. So until we have preview in that dialog, I'm not sure this is a good idea. But if you really need it, the correct way to do it is to have a "locked" toggle button, on by default, which ungrays height when unlocked.

No. I want locked aspect ratio and ungrayed height. I often want to specify my output size it terms of height not width. It is a pain to flip through widths until the height is what I want. All of the dimension inputs I've seen in the GIMP are this way: locked aspect with the ability to change either height or width. (Ff course in GIMP there is ability to unlock aspect which I don't need.)

Aaron Spike

Hi,

...

...

Can't "Export bitmap" be turned into "Export", offering a choice of bitmaps, and remembering the chosen filename?

"Export bitmap" has a lot of bitmap-specific options, so I don't think we can combine it easily with vector export. However I do agree that "Save as" is not the most logical place to look up for EPS export. Perhaps we should separate that into an "Export vector" command.

I am still following this list although I am not a developper at all and maybe all this discussion will be more suited in the users or testers mailing list but still... here are my 2 cents.

On this particular issue, I think that many other popular applications do the wrong thing. For example, in Adobe Illustrator you can save as EPS, PDF, AI, SVG. As Gavin I think that "Saving as..." should provide you with a complete and editable file and I think that this is the basic idea of any user. But then, depending on the save options you can end with a non editable PDF file, or a file without transparency (EPS) and so on. To go a little further on this topic, something that I find even more confusing is that you what you see when you work on the file is not what is saved. For example you can create a new file (foo.ai), create some gradients, transparent shapes and then save it as EPS. Nothing changes in your editing window except that the file name in the title bar is foo.eps even though this format does not support transparency. Then you save it (in EPS) and only when you try to quit a warning message tells you that you might loose something in your document (and as a newbie, you have no idea what). So why not saying/showing that earlier! In addition, if you are confident in your "save as" dialog you might just save the file anyway and loose all your nice gradients just because the menu is not well organized. And the orignal foo.ai does not help you so much because you have done most of you editing on the EPS file.

From a programming point of view I understand this behaviour: the

image you work on is what is in memory not what is saved on the disc. But I think that, from a user point of view it will be much better to see immediatly what saving is EPS makes you loose (and make this undoable of course). For example you might have to provide some EPS illustrations for an article you are writing, you notice that illustrator or inkscape can provide you with these EPS and you start editing your nice EPS files with lots of gradients, transparency... which end up in a mess because you didn't knew about the limitations of EPS. Exactly the same happens with the Photoshop when you save a multi-layer fille to JPEG, and still keep you multiple layers in the editing window. And there are many other examples...

To sum up (I apologize for all this beeing a bit long) I support Gavin and think that "save as" or "save a copy as" should save to format in which no information is lost and that everything else should be "export". From a user point of view I think this is more self-explanatory because it makes you to consider two different files: the original where all the information is and the exported one where you can imagine that some information is lost, and more secure because you still have the original one where you made all the editing.

For the organization of the export dialog, three dialogs seem a little to many for me, especially in this situation. Exporting make you loose information so you might what to check quite often what your SVG will look like when exported. Too many dialogs will make the export a little painfull. But then one unique dialog for bitmap and vector might be confusing too because the options are very different, as previously said. Furthermore, making a clear distinction between vector and bitmap will be great for teaching the user that there is a difference (I still hear many people that don't really understand why their JPEG print so badly while my PDF look great). If you don't what to add too many menu items (two exports) the solution could be a tabbed Export window with a "bitmap" tab and a "vector" tab. In each one the user can set the options and the filename and the options of the two tabs will be remembered (as it is the currently the case with the bitmap export) so that exporting several times your document during the editing process will just be a matter of clicking OK or clicking a tab and then OK.

I hope this was not too long but I think that if Inkscape, in addition of beeing a great software, could teach good image editing practices to its newbie users it would be a great "advantage" in comparison with other big softwares aimed at professional graphic designers (but used anyway by everybody so that the results are not always great ;-) )

Thanks again for this software.

On 9/2/05, Gavin Band <gavinband@...663...> wrote:

...

can't zoom out far enough. So, what do you propose? Unlimited zoom-out is impossible.

Is there some compelling technical reason for this?

Apart from "running out of bits" as Mental said, a more important reason is usability. If a program allows a user to go somewhere infinitely without a limit, it basically allows that user to shoot him/herself in the foot. Keyboard keys may stick, intentionally or unintentionally; what's worse, zoom is stored in the file and restored on load. All this may lead to situations where you you don't see anything on screen "no matter how long" you try to zoom in (i.e. you need to do it for a really long time but you don't know how long). If you are unaware of the zoom value field and the shortcuts such as "zoom to drawing", the program appears broken to you.

From a user's point of view, this seems like an unnecessary restriction - one expects to be able to zoom out as far as one wants

That never was a problem with regular-sized images, only with this large one. Again, I can and probably will make max zoom-out far enough for this particular image, but there will always be larger ones.

That's true. It seems to have a top section for choosing what part of the picture to export; and a bottom section including dpi and resolution boxes (and on my machine, the "Height" part seems to be greyed out).

Why not have a further section for file type, and grey out the resolution boxes if they are not relevant?

Choosing export area is also bitmap-only. For vector export, we may only select which _objects_ to export (though we don't currently have code for this, always exporting the whole image), but not the export area. That only makes sense for bitmaps.

Or have a sequence of two or three dialogs: first box: choose area of screen to export; second box: a standard "save as" dialog with the usual browser; third box: filetype-specific settings.

That's what e.g. Xara does: on "Export", first dialog is filename and file type selection, and the second one is the bitmap export settings _if_ you selected a bitmap format in the first dialog. However this is atrocious usability, I don't want us to follow this example. Having to go through two dialogs for simple export is crazy. Our bitmap export dialog with filename in it, which can be always on and tracks current selection, is infinitely more convenient. So I agree that the current bitmap export dialog can be improved (e.g. by adding other bitmap formats, or live preview in a separate pane), but I would object to breaking the filename part out of it.

(I suppose I'm thinking of the GIMP, it has "Save as..." and "Save a copy" and in both cases one first chooses the filename and then, depending on filetype, is are presented with a dialog asking for filetype-specific options.)

That's what we have too for vector formats. You save as EPS and then you get a dialog with EPS options. Makes sense for vector exports but not for bitmap, as I explained above.

On 9/2/05, Gavin Band <gavinband@...663...> wrote:

Well, I wasn't thinking that there would be no limit; rather that the limit would be when whole picture is (say) 1/16th of the size of the window. That would avoid the problem you mention, yet still allow any image to be viewed in its entirety.

You seem to assume that the zoom is relative to the picture size, but in fact it's rlative to px unit. So if you limit it to be able to show this particular file, nothing prevents someone from creating a new file 16x bigger (in px units) that still won't fit, and so on ad infinitum.

On 9/2/05, Gavin Band <gavinband@...663...> wrote:

Well, isn't that from a technical viewpoint rather than a user's viewpoint? I mean the "View" menu makes no mention of px units. Indeed (if a "px" is a pixel), what is a pixel in a vector drawing program?

No, it's entirely from user viewpoint. And the view menu _does_ use px units, though it does not mention it by name. The 100% zoom level is _defined_ as the level at which one px is shown as one screen pixel. That's because all SVG renderers I know show images at this zoom by default, so it makes a lot of sense to call this 100% in Inkscape. Naturally, all other zoom levels are relative to this 100% zoom and therefore to px unit.

p.s. is there a maximum image size as well? if I zoom right out and add rectangles at the edge, the canvas doesn't seem to grow to accomodate them.

Sorry - ignore that - it does grow. gav.

Oh, and I forgot to mention: I think even the SVG spec recommends that one user unit (px unit) should correspond to one output pixel, unless output pixels are too small (e.g. on print). So, one might say that the level of zoom that Inkscape calls 100% is given directly in the spec.

On 9/2/05, Gavin Band <gavinband@...663...> wrote:

Well, isn't that from a technical viewpoint rather than a user's viewpoint? I mean the "View" menu makes no mention of px units. Indeed (if a "px" is a pixel), what is a pixel in a vector drawing program?

thanks, gav.

Quoting mental@...3...:

He was suggesting that the zoom level be constrained so that the full extent of the objects in the document would span no less than 1/16th the area of the viewport.

I assume this would be for zooming out, of course.

-mental

Quoting Gavin Band <gavinband@...663...>:

On Fri, 2005-09-02 at 17:17 -0400, mental@...3... wrote:

...

Of course that does raise the question of what to do if you

enlarge

...

the window when you're already at the limit.

Ah...well ok, make the limit when the picture is one (screen) pixel big; then it doesn't depend on the window size.

I don't know ... one screen pixel big sounds too small to be useful.

I think I'd prefer the 1/16th area heuristic, and zoom in as required if the window is expanded.

-mental

On 2005-09-02, bulia byak <buliabyak@...400...> wrote:

On 9/1/05, Gavin Band <gavinband@...663...> wrote:

...

it's impossible to zoom out so one can see the whole picture at once.

Well, as you understand, we must have some minimum limit to zoom, and no matter how far it is, there will be documents so large that you can't zoom out far enough. So, what do you propose? Unlimited zoom-out is impossible. We can stretch it to accommodate this particular file, but there will always be still larger ones.

How about a 'fit to window' or 'fit to screen' with the minimum calculated dynamically?