The Object Properties dialog box has properties Visible and Printable.
Currently, we map Visible in the Object Properties dialog to SVG's visibility attribute, while we use a custom attribute for Printable.
When would in-inkscape visibility differ from on-paper visibility?
- Visible on screen but not printable for guide lines/shapes.
- Printable but not hidden [or 90% transparent?] on screen for temporary editing convenience.
I'd guess that the user wants the same things to be printable as they want to be exported to PNG or generally visible as part of the image to be seen by viewers.
If "seen by viewers" includes the use of other SVG agents (e.g. use of a command-line tool for printing or exporting to another format, or embedding in e.g. HTML before printing), then that suggests we should use SVG's visibility property for Printable, and use custom data to indicate what things are currently visible/hidden.
Comments?
pjrm.
I'd guess that the user wants the same things to be printable as they want to be exported to PNG or generally visible as part of the image to be seen by viewers.
I don't have much experience with printing from vector editors, but I agree with that. I think that a separate "printable" attribute is evil. It's a sure way to get costly suprises when you discover that you wasted paper and ink because some element had this attribute set or unset contrary to your expectations. It's especially bad since there's currently no way to preview what is printable and what not, other than to print it (or, at least, print to file and view the file, which is still very inconvenient).
If "seen by viewers" includes the use of other SVG agents (e.g. use of a command-line tool for printing or exporting to another format, or embedding in e.g. HTML before printing), then that suggests we should use SVG's visibility property for Printable, and use custom data to indicate what things are currently visible/hidden.
Yes, and more than that: I think we don't need any custom visibility attribute at all. Auxiliary things like guides are not visible in external SVG renderers anyway, because they do not correspond to anything in SVG. And as for regular SVG objects, I'm sure that hiding/unhiding anything in Inkscape must hide/unhide it everywhere. This is the simplest and least nasty-surpriseful approach, and I don't see any reasons to do otherwise. So, my opinion is that we must only use the visibility CSS property and nothing else.
On Sat, 2004-11-06 at 11:36, bulia byak wrote:
I'd guess that the user wants the same things to be printable as they want to be exported to PNG or generally visible as part of the image to be seen by viewers.
I think that a separate "printable" attribute is evil....So, my opinion is that we must only use the visibility CSS property and nothing else.
Strongly agreed.
Anyway, if someone someday really absolutely needs something to be rendered on a display but not printed, they should eventually be able to use the standard CSS @media stuff. It's not something we should have a special case for.
-mental
I think that a separate "printable" attribute is evil....So, my opinion is that we must only use the visibility CSS property and nothing else.
Strongly agreed.
Anyway, if someone someday really absolutely needs something to be rendered on a display but not printed, they should eventually be able to use the standard CSS @media stuff. It's not something we should have a special case for.
On the other hand, it occurred to me that we may want to use arbitrary objects as guides (as some other vector editors do). Such objects would have to be SVG objects but, as guides, only visible in Inkscape. How to handle them? One idea is this: store such objects in <defs> with an inkscape: attribute telling Inkscape that they are guide objects and must be displayed correspondingly. Other renderers will naturally just ignore then and yet we will be able to store arbitrary SVG for our purposes.
-mental
On Sat, 2004-11-06 at 13:21, bulia byak wrote:
On the other hand, it occurred to me that we may want to use arbitrary objects as guides (as some other vector editors do). Such objects would have to be SVG objects but, as guides, only visible in Inkscape. How to handle them?
One idea is this: store such objects in <defs> with an inkscape: attribute telling Inkscape that they are guide objects and must be displayed correspondingly. Other renderers will naturally just ignore then and yet we will be able to store arbitrary SVG for our purposes.
I think the best thing to do would be keep them in a <defs> as you suggest, but instead of a special attribute reference them at their place of use with an inkscape-namespaced element that behaves like <use>, but creates guides rather than normal rendered/editable instances.
Directly rendering objects in <defs> is probably not a good idea.
-mental
participants (3)
-
bulia byak
-
MenTaLguY
-
Peter Moulder