SVGFonts UI discussion thread
Currently SVGFonts rendering in a helper GtkWindow is working ok for glyphs described using the path descrition ("path:d") attribute. Once we move the rendering to the canvas, arbitrary chunks of SVG will be added to the glyphs. Currently glyph kerning and missing-glyph nodes are also properly handled and rendered.
I am using the helper GtkWindow because we still don't have pango+userfonts integration. So I am using cairo+userfonts directly on the GtkWindow. Once pango supports userfonts, I will remove the GtkWindows and render SVGFonts on the correct place (directly in the canvas). Since my work now depends a lot on this pango support, it has been evolving very slowly. I am thinking of doing some user interface work while we are stuck with pango.
So, this thread is intended to discuss ideas and mockups on what people want to see for the SVGFonts user interface. Mental told me yesterday that it should be possible to edit glyphs on canvas directly on the rendered text in an "edit fonts" mode. I agree that this is the ideal thing to do, i.e. have things rendered in real time as much as possible. For example, when the text "Felipe" is rendered using an SVGFont and the user goes to "font edit mode", then editing the content of one of the "e" glyphs would make both "e" glyphs to be visually modified as if they were clones. That is the desired "real time" on-canvas bahaviour.
But I also think that there should be an off-canvas glyph-editing user interface. There must be a dialog where the user can define the glyph-names, metadata such as font-family name and all the other font descriptors, the missing-glyph curves, and all of the glyph-kerning rules. Also, in this off-canvas UI, we could/should have helper lines indicating font metrics information such as base-line, top-line, etc. just like a font-editor would be.
I also have in mind a unicode codepoint selector widget to be used for the u1 and u2 attributes in the kerning rules dialog.
Please, feel free to offer new ideas or to say my ideas are crap or whatever. I am open to discussion.
JucaBlues
2008/6/23 Felipe Sanches <felipe.sanches@...400...>:
Currently SVGFonts rendering in a helper GtkWindow is working ok for glyphs described using the path descrition ("path:d") attribute. Once we move the rendering to the canvas, arbitrary chunks of SVG will be added to the glyphs. Currently glyph kerning and missing-glyph nodes are also properly handled and rendered.
Wow - great work! :-)
I am using the helper GtkWindow because we still don't have pango+userfonts integration. So I am using cairo+userfonts directly on the GtkWindow. Once pango supports userfonts, I will remove the GtkWindows and render SVGFonts on the correct place (directly in the canvas). Since my work now depends a lot on this pango support, it has been evolving very slowly. I am thinking of doing some user interface work while we are stuck with pango.
Okay cool :-)
So, this thread is intended to discuss ideas and mockups on what people want to see for the SVGFonts user interface. Mental told me yesterday that it should be possible to edit glyphs on canvas directly on the rendered text in an "edit fonts" mode. I agree that this is the ideal thing to do, i.e. have things rendered in real time as much as possible.
I'm not sure its very useful to making new original type designs, but I can see being very useful for making a few small tweaks to an already-complete font and seeing the effect "globally" on a piece of text. And since that is what a lot of Inkscape users will want to do, I think its a great idea :-)
Its wonderful for populist designers like me, sure to be hated by the (sadly, majority of professionals) elitist ones :-)
As tried to explain in my blog post [1] developing a typeface means drawing at "multiple levels" so to speak - editing a glyph is the lowest level, then editing the metrics is another, and then testing the type in different kind of paragraphs is another.
[1]: http://understandinglimited.com/2008/06/09/proposing-inkforge/
For example, when the text "Felipe" is rendered using an SVGFont and the user goes to "font edit mode", then editing the content of one of the "e" glyphs would make both "e" glyphs to be visually modified as if they were clones. That is the desired "real time" on-canvas bahaviour.
I suggest a button on the contextual toolbar for this which becomes clickable when a single glyph is selected in a text box; clicking this "edit selected glyph" button, the selection inverts so that the canvas around the glyph is greyed out, and the "edit paths by nodes" tool is selected so that the points of the glyph's paths become visible. Additionally, the 'bounding box' that appears is not that of the paths but of the glyph, with the left and right sides having on-canvas sliders like bounding boxes do, which will edit the left and right bearings. There are layers specific to glyphs and to this particular glyph, and all guides have labels attached. The layers drop down on the status bar changes to list glyphs instead of layers, so that other glyphs can be selected by name.
1editglyph.png attached for a sketch :-)
But I also think that there should be an off-canvas glyph-editing user interface.
Yes, this needed for metrics especially, but also for editing glyphs so that glyphs can be compared. The metrics window in FontForge is a fine example.
There must be a dialog where the user can define the glyph-names, metadata such as font-family name and all the other font descriptors, the missing-glyph curves, and all of the glyph-kerning rules.
I suggest this works much like the XML Editor dialog's interface.
Also, in this off-canvas UI, we could/should have helper lines indicating font metrics information such as base-line, top-line, etc. just like a font-editor would be.
I think these can be on canvas too, but yes having a more systematic view of them would be good. :-)
Please, feel free to offer new ideas or to say my ideas are crap or whatever. I am open to discussion.
Hope to make more sketches soon :-)
Cheers, Dave
On Mon, Jun 30, 2008 at 8:45 PM, Dave Crossland <dave@...1555...> wrote:
1editglyph.png attached for a sketch :-)
I may be a "populist" as well, but I like this :) No clumsy additions or unnecessary restrictions, everything is pretty obvious. Felipe, if you need help implementing that (e.g. the blue screen around the letter box) let me know.
definetly I do! What can you tell me about that? What are the basic principels for putting stuff on inkscape canvas?
On Mon, Jun 30, 2008 at 9:28 PM, bulia byak <buliabyak@...400...> wrote:
On Mon, Jun 30, 2008 at 8:45 PM, Dave Crossland <dave@...1555...> wrote:
1editglyph.png attached for a sketch :-)
I may be a "populist" as well, but I like this :) No clumsy additions or unnecessary restrictions, everything is pretty obvious. Felipe, if you need help implementing that (e.g. the blue screen around the letter box) let me know.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Mon, Jun 30, 2008 at 9:42 PM, Felipe Sanches <felipe.sanches@...400...> wrote:
definetly I do! What can you tell me about that? What are the basic principels for putting stuff on inkscape canvas?
Since this thing is helper display, i.e. not an object in a document, you create a CanvasItem for it. There are several kinds of them, what you need for this is CtrlRect in display/sodipodi-ctrlrect.cpp. It is used for example for the rubberband and selection rectangle. You can set the fill color and opacity level for such a rect. You can't make a hole in it, though, so you probably need to manage 4 such rects to surround the letter box; it may be a good idea to create a new kind of canvasitem for such "mask with hole". Alternatively, you can use display/canvas-bpath.cpp, which can display any path, then you can just make the hole as a subpath, same as in SVG. However the bpath may be slower to render because it uses cairo, whereas ctrlrect just bit-flips the rectangle. I'm not sure the difference would be noticeable, though.
See e.g. rubberband.cpp for a life cycle of a canvas item - it creates a box (for regular drag selection) or a path (for touch selection), sets their properties, updates coords, then deletes them when no longer needed. Copy code from there.
In addition to that, you will probably need to lock all objects other that the glyph you're editing. Since the glyph will be in defs, you just need to temporarily lock all regular layers. This is easy to do with item->setLocked, but the problem is that this must not be permanent locking that gets written to SVG - when you quit and reload the file, it must have its layers in the original locked/unlocked state. Mental, can you suggest a solution to this?
On Mon, 2008-06-30 at 22:13 -0300, bulia byak wrote:
Since this thing is helper display, i.e. not an object in a document, you create a CanvasItem for it. There are several kinds of them, what you need for this is CtrlRect in display/sodipodi-ctrlrect.cpp. It is used for example for the rubberband and selection rectangle. You can set the fill color and opacity level for such a rect. You can't make a hole in it, though, so you probably need to manage 4 such rects to surround the letter box; it may be a good idea to create a new kind of canvasitem for such "mask with hole". Alternatively, you can use display/canvas-bpath.cpp, which can display any path, then you can just make the hole as a subpath, same as in SVG. However the bpath may be slower to render because it uses cairo, whereas ctrlrect just bit-flips the rectangle. I'm not sure the difference would be noticeable, though.
I wouldn't worry about speed yet at this point. Creating a new canvasitem type for "mask with hole" seems like a good idea. For now, just do enough that it can have a rectangular hole and don't make it overcomplicated, but in the future we might extend it to have other kinds of hole.
In addition to that, you will probably need to lock all objects other that the glyph you're editing. Since the glyph will be in defs, you just need to temporarily lock all regular layers. This is easy to do with item->setLocked, but the problem is that this must not be permanent locking that gets written to SVG - when you quit and reload the file, it must have its layers in the original locked/unlocked state. Mental, can you suggest a solution to this?
Well, we definitely *don't* want to be locking things at the SPItem level and then having to "fix up" SVG data to hide that fact. Ideally it should be a strictly canvas-level or arena-level thing.
I think we may need to back up and do a redesign of the way click sensitivity/canvas picking is handled. It's likely to be less work than the gymnastics required to hack something this up with the current approach.
My current idea is to have each arena object carry with it a set of "pick flags", some of which are defined to make an arena item eligible for picking, and some of which are defined to definitively exclude both an item and its descendants from being picked.
Rather than having a single "transparent" flag, we could then have at least two flags: "simple object" (which makes an object eligible for picking), and "locked" (which excludes an object and its descendants from picking).
Normal arena items would have "simple object" set, but layer arena items would not, so that a pick would not consider a layer, but would still examine any eligible descendants.
Any locked arena item would simply have the "locked" flag set, excluding it and any descendants from picking even if they'd otherwise be eligible. This approach would remove the present need to recursively set/clear "transparent" flags on lock/unlock transitions.
How this scheme would be applied to "<defs> editing" depends a great deal on where the <defs> object's arena items are to be put in the arena item tree. Probably we would set additional flags on a few key arena items and possibly modulate which flags picking paid attention to.
-mental
participants (4)
-
bulia byak -
Dave Crossland -
Felipe Sanches -
MenTaLguY