- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] UI proposal for text in shapes
by Valerie 04 Jun '08

04 Jun '08

> but as an aside, the whole typeface generation engine is still very > much in development, and i'd venture to say that a stable/usable > version will not be out before August. I have been working on an > Inkscape plugin for testing it, so maybe that would be a better way to > introduce this type design interface into Inkscape - then we can talk ;) I can't help with that unfortunately, I have no idea what you'd be trying to achieve UI-wise. On the bright side, I've thought up a possible interface for the toolbar. However, I'd suggest the option to revert to "simple" mode for those who aren't used to it. The fontface choices would basically be done in a drop-down: http://img147.imageshack.us/img147/7818/textstylesmk2.png (rough drawing for now, I'll do the nicer looking version later) Mouse-over the values will also reveal their names (bold, ultra-bold, heavy etc) Now it would still be cumbersome no matter what you do because there are just that many options. However, Mouse-over to Each field Must reveal the shortcuts, which would get the users to quickly get used to them and thus minimize their usage of the drop-down. Shortcuts: - Ctrl+I: toggle between italic modes (normal, oblique, italic) - Ctrl+B: make bolder. - Ctrl+Shift-B and Ctrl+L: make lighter. - Ctrl+E: expand. - Ctrl+Shift+E: contract If gravity is added in there, then sure. As for "weight," it'd go like this: if for a style (say, Italic), there is no font for that weight, they the implicit weight value stays the same, but Italic takes on the next closest value. The explanation to the user is that "Italic with Bold" and Italic with Ultrabold" look the same. And that's about it. A possible alternate interface is that Italic gets drop-down value boxes and Bold next to it gets a drop-down horizontal slider. The other options still get stuffed into a drop-down.

1 0

Knotholder C++ification
by Maximilian Albert 04 Jun '08

04 Jun '08

Hi all, in rev. 18775 I committed some changes to C++ify the knotholder-related classes (this was made necessary by my LPE-integration work). Basically, I just rewrapped the existing functions as methods of the new classes KnotHolder, KnotHolderEntity etc. Although the changes were quite straightforward, there is a chance that some code got lost in the process, so please watch out for any regressions!! The main change to be aware of when writing new knotholder code is perhaps that each knotholder entity (which among other things encapsulates a visual on-canvas handle) should now derive from the "general" KnotHolderEntity class and override the virtual functions knot_(get|set|click) which are responsible for the actions taken when the associated handle's position is read/set or when the handle is clicked. Similarly, each item-specific knotholder class (like RectKnotHolder) now derives from the general KnotHolder class, and in its constructor the necessary KnotHolderEntities for all required handles are created. Note that a KnotHolderEntity must currently be explicitly created using the create() method (i.e., this does not happen in the constructor).[1] I'd welcome any comments because although it works well, it still seems slightly awkward to have a new class for each knotholder entity and each knotholder. Did I miss anything and is there a more elegant way to organize things or is this indeed the way to go? More on my other and yet-to-be-committed work in a separate email. Cheers, Max P.S.: Known issue: LPE PointParams are currently broken and they cannot be edited on-canvas. I hope to get this fixed very soon and then the cumbersome edit-on-vanas button will disappear, too. :) [1] I know that there used to be a good reason for this but it may be the case that due to some later refactoring it's not necessary any more to have it this way. In any case, I left it for now because it slightly declutters the declarations of the derived classes. Please tell me if you want it changed.

1 0

Eraser "Polar bear in a snowstorm" fixed
by Jon A. Cruz 04 Jun '08

04 Jun '08

Just a quick FYI... I fixed the "polar bear in a snowstorm" problem with the eraser tool, in which it was always using the last style used and would be hard to see. The preferences are now in the UI, and the defaults should be set up nicer.

1 0

SVG Filters optimizations
by Felipe Sanches 04 Jun '08

04 Jun '08

I have seen an article (in the Beautiful Code book that Google sent me as a SoC gift) about runtime code specialization/compilation using C# in order to optimize code. I was thinking about using similar things to optimize our SVG Filters code but I don't know whether this kind of thing is possible in C++. C# can run bytecode generated in runtime. How could that be achieved in C++? I also have seen an article about a library for C++ that seems to do exactly this, but the lib is non-free: TaskGraph (http://www.doc.ic.ac.uk/~phjk/Software/TGL/) Is there a free-software lib for this? Juca

2 1

NEW : LPE stacking
by Steren Giannini 04 Jun '08

04 Jun '08

Hello, Our student project is now finished. Thanks to our mentor Johan, our work is now in main trunk. For us it is a real pleasure to see that. Our goals were : - LPE stacking : Check it out - LPE for groups : has already been committed - LPE envelope : we created 2 deformation effects, the first one is "Envelope", the second is "Lattice" and is based on the d2sb2d object from 2geom. They are not designed for the same use. Indeed, while the lattice offers an accurate deformation, this deformation is only determined by control points. It also allows the user to move inner control points, which can't be done with the Envelope deformation. The power of the Envelope deformation is the absolute control of the shape of the envelope. We made lots of efforts to correct bugs we found, but you may find some more. Concerning the school, our teachers told us our project is one of the best of this year. They qualified it of "excellent project" and they were very glad to see our results. I hope this will spur the students on to work on open source project. I intend to continue working on Inkscape, first by "polishing the edge" of our actual work and then by adding things I have in mind. I hope people will like and use what we did. Thanks again Johan and the inkscape community, The team : De-Cooman Aurélie Tebby Hugh Falzon Noé Bouclet Bastien Navez Victor Giannini Steren

5 6

Re: [Inkscape-devel] UI proposal for text in shapes
by Valerie 03 Jun '08

03 Jun '08

> You choose font family, say, DejaVu Sans and normal face > > Since DejVu Sans also has Bold and ExtraLight faces, when you choose > "bolder", Inkscape uses Bold face, if you then choose "lighter", it > goes back to normal and then to ExtraLight face. With "italic" enabled > it will only cycle between Oblique and Bold Oblique, since there is no > ExtraLight Oblique right now. ... http://img382.imageshack.us/img382/8519/textstylesdq3.png (eww) > It's not implemented right now, because we need help from Pango > (http://www.pango.org/). And at latest Libre Graphics Meeting in May > it was discussed with Behdad from Pango team. Alright, alright, I think I get it more. It's fine for keyboard, I suggest just going with Ctrl (or Alt) and the directional keys in text mode. They don't seem to be taken in text mode. Simple right? For the top level interface though, there's the problem of what takes precedence. The drop-down can still be used, but the available values of one would depend on the available values for the other, as you've given with the example of Italics. And I Really doubt people would want to see a check box system. Ah great, I just took a look at the Pango manual. There's a whole series of bold values in there And stretch (and a few other things. What, pray tell, is "font mask gravity"? Well, fortunately, there are only 3 values of Italics: normal, oblique and italic, so that can be the starter value: once you've chosen one of those, the available bold and stretch values pop out, all of which could still be set to a slider interface. A button somewhere could show a matrix of what's available in each mode (...). Have you set a date for when you'll be discussing with the Pango people? It'd be a Lot easier to think up an interface if I actually knew what needs to be implemented. As I've said, keyboard-wise, just go with modifier key + directional arrows. Up-down for bold, right-left for stretch (hey, that's pretty intuitive!). For the rest though... > With such modular typeface engine, we could have fonts where you > can modify stuff like how bold you want your font - though > obviously only on fonts generated with the same engine. Nice concept, except people will probably be expecting a lot more than the modifiable fonts. On well. :( Anyway, I have to log off for today. One of these days I may try to look into Pango more, but that'd take some time since I really don't know much about fonts. Unless someone else knows how to deal with the issue instead? :)

1 0

Re: [Inkscape-devel] UI proposal for text in shapes
by Valerie 03 Jun '08

03 Jun '08

> Just a quick note: we are to move away from Bold/Italic paradigm to > better handling of various type faces and we are likely to use > "less/more bold" paradigm. This is not set in stone yet, of course :) Oooh! :) Um, how is it supposed to look like? :P (because I have no idea what you're basing this off. XP Any bugs or examples of programs that do this, so I can include this in the interface?)

2 1

Re: [Inkscape-devel] UI proposal for text in shapes
by Valerie 03 Jun '08

03 Jun '08

Alright, here's what I've got for now (below is the draft of what I'd put in the wiki): Text-UI-improvements Text UI with space, kerning, path and flow Summary: An improvement of the text toolbar functionalities, adding: spacing, kerning, put-on-path, flow-into-shape (with auto align and padding values) and perhaps more font styles (underline, etc.). All this is done without making the toolbar excessively long via usage of drop-downs. http://img135.imageshack.us/img135/5168/textinterface1ix1.png The interface: - (by the way, can the font size value drop-down be made slightly smaller?) - clicking on "Spacing" pops up a temporary drop-down, where you can set the line spacing and letter spacing values. Clicking anywhere else closes it. It is assumed that users would not need to modify these Too often. - the "horizontal layout" button is eliminated to save some space. - more font styles are accessible from the toolbar. However, this may take too much space, so see below for alternate toolbar. - Kerning is also accessed via a drop-down. There you can set values manually, but mouse-over will reveal the shortcuts, so users quickly learn how to manually do kerning instead of having to use the drop-down all the time. A button enables the user to remove all kerning. - the "put text on path" operation is included onto the text toolbar. To use it, you simple select both the text and the path, and click the button. Clicking again removes the operation. - the "flow text into shape" is very useful for charts and comics. However, the current operation is too limited because of the absence of padding and alignment options. More precisions below. Note that I have made heavy use of down-downs. There are two major differences between such drop-downs and popping up a whole Text dialog that makes them hopefully more pleasant to use: - they're Smaller. i.e., less cumbersome. You can access exactly the operations you need without popping up something huge in the middle of the screen. - they disappear as soon as you click elsewhere, so you quickly get them out of the way. - and yet they still allow you to quickly access some operations that are hopefully not Too frequent. Precisions on the "flow into shape" section: - I often make charts, and it is extremely cumbersome to bring up the align dialog all the time just because I want to align a text to the center of a shape. Ideally, this should be automatic. I forgot who first came up with the align grid for Inkscape, but credits goes to him! :) The align grid is as its name implies: clicking on the center aligns the text to the middle-center of the object (as is often the case for chart items and comic bubbles), the top-left option is most use for text boxes. Right- alignment would be handy for Asian layouts. See examples: http://img176.imageshack.us/img176/7099/alignmentbc9.png - Also, the padding is automatic: it basically automatically creates a shape inset of that value, and flows the text into the invisible shape. This way the form can finally be used as the actual border of the frame instead of other complicated work-arounds. - Ideally, the x and y values of padding could be set independently, but it is otherwise not really a problem because in the case of comic shapes, for example, the text would be aligned to middle-center so the top and bottom borders will rarely be reached. Alternate interface: the following interface presents ideas to further reduce toolbar length: http://img260.imageshack.us/img260/8550/textinterface2nb3.png - the text align options would be reduced to a single button with a horizontal drop-down. However, users would probably like to have these options at top-level. - instead of cluttering the bar with font styles, another drop- down could be used. What goes into this drop-down depends on who plans to stuff it: it can be more buttons, check boxes, even complex drop-downs like Open Office (though hopefully not That complex and not That big). This allows users to access a wide range of rare styles as they are made available. - if the x and y padding values of "border" for text flow can be modified separately, then they get grouped into a drop-down as well. Anyway, I know many of you are busy. I'll probably leave this proposal up for about a week, and in the meantime, I'm open to any additional suggestions, or I'll wait longer if anybody gives a more specific date on when they'll have time. As you can see, many of the elements have several possibilities, so there could be additional refinement there as well. :)

2 1

RM's pencil smoothing and tolerance UI: anybody?
by Valerie 02 Jun '08

02 Jun '08

I've tried to apply this patch: https://bugs.launchpad.net/inkscape/+bug/188381 As you can see, it works, even though I know nothing about patching: http://img206.imageshack.us/img206/106/tolerancecp9.png Since there is a working patch available to enable tolerance control from the toolbar, is there any reason why it hasn't been committed? (apart from the fact that tolerance control does not work from the pref window, but if you can access it from the toolbar, there is no reason to modify it from prefs anymore). This, however: https://bugs.launchpad.net/inkscape/+bug/188849 Gives me errors (mostly ¡®sp_curve_unref¡¯ was not declared in this scope and similar) Unfortunately I have no experience no the matter. Is anybody else looking into the matter? Better smoothing would be so very welcome.

2 2

Bug with preferences
by Jon A. Cruz 01 Jun '08

01 Jun '08

There's a new bug with preferences that might be the sign of a problem in XML writing. https://bugs.launchpad.net/inkscape/+bug/236485 I won't have time to look at this until later in the afternoon. However it looks to most likely be a bug in either the PrefCombo class or our XML writer itself (given the recent changes there).

1 1