GNOME Bugzilla – Bug 162034
Better font scaling needed - does Pango evolution help?
Last modified: 2019-03-20 11:16:26 UTC
Too well known: Dia has a problem scaling fonts. The problem: For diffenrent zoom level the text should scale linear with the other diagram elements. But font scaling isn't that simple - i.e. the text width does not scale linear with the height. The current approach: a loop feeding tweaked font heights into Pango until the text has almost the desired width. Obvious drawback - so slow that it needs a cache. Also sometimes this approach fails cause Pango simply does not deliver the right sizes: WARNING **: Failed to appropriately tweak zoomed font First try : Use the new (Pango 1.6, 1.8?) render_transformed facility. With a matrix it should be possible to scale the text linear - that is keep the font size as the user selected it and adapt for zooming with pango_context_set_matrix() But looking at the results produced by the following patch it does not work as expected ;( Maybe either because there are bugs in the patch - or worse because my interpretation of applying a matrix to a font and that of Pango differ) Having found only one FC_Set_Transform() in all of Pango I suspect the latter ...
Created attachment 35149 [details] [review] usage restricted to libart renderer
Tried yesterday with the new Gtk justification, and it seems to work nicely. So this may not be needed.
Hi Lars, maybe I'm just lacking the power of imagination but I fail to see how your code can have any positive effect. Also I didn't find anything about new "Gtk justification". The only thing I see is: /** * pango_layout_set_justify: * @layout: a #PangoLayout * @justify: whether the lines in the layout should be justified. * * Sets whether or not each complete line should be stretched to * fill the entire width of the layout. This stretching is typically * done by adding whitespace, but for some scripts (such as Arabic), * the justification is done by extending the characters. * * Note that as of Pango-1.4, this functionality is not yet implemented. **/ The comment appears to still be true for current Pango cvs ...
Pango justify was the thing, yes. My *hope* was that by setting it to justified and no wrapping with a size corresponding to the 100% zoom size, it would get letterspaced to the appropriate size. I guess I've been confusing my Pango versions with Gtk versions. That'll teach me to hack while sick. I guess my tests weren't thorough enough to catch the lack of adjustment. No less confusing is that the Pango web page calls the newest Pango 1.2, the API docs say 1.7, ftp.gtk.org has 1.8 for download... That patch is a major bit of work. Why testing whether the matrix does what it's supposed to do, I'd have kept that inside font.c to make sure the other changes don't disturb me. Do you have a good diagram for testing whether scaling works right, BTW? Marking as NEW, btw.
Created attachment 38635 [details] a 'random' test diagram using UML As noted above your patch looked rather suspicious to me (cause there is no implementation in Pango backing it). I'm about to attach two screenshots of the given diagram at scale 50%, which make the ill effect of the patch rather obvious. Finally I'll attach your patch here and revert lib/font.c to the working version.
Created attachment 38637 [details] screenshot produced with lib/font.c(1.125) How it looked before applying the patch: http://cvs.gnome.org/viewcvs/dia/lib/font.c?r1=1.125&r2=1.126 (I'd say how it *should* look)
Created attachment 38638 [details] text rendering broken (though faster;)
Created attachment 38639 [details] The change which does not work as desired. See also: http://cvs.gnome.org/viewcvs/dia/lib/font.c?r1=1.125&r2=1.126 It may be reconsidered if pango_layout_set_width() has any effect.
BTW: what strikes me odd ist the constant modification most functions in lib/font.c do to the [in] parameter 'font'. Maybe we need to clean the API at first before trying any improvements on the implementation ?
Not sure which modifications you're talking about. Cleaning up the API is probably not a bad idea overall, though. I'll badger the pango people a bit about the Right Way[tm] to do scaling.
Badgering at http://mail.gnome.org/archives/gtk-i18n-list/2005-March/msg00005.html
Again a change to get this out of unreviewed patches ;)
Comment on attachment 35149 [details] [review] usage restricted to libart renderer Some parts of this patch are in there, the Pango stuff needs versions of Pango that SuSE doesn't have yet. The end_render/begin_render parts I don't get -- data_render should have that encapsulated. This also looks at several other issues not really related to the font width issue.
Comment on attachment 38639 [details] The change which does not work as desired. Not currently in CVS, and I see the problems. Keeping it out of there. However, we should probably look at using a given width rather than 'the width at 100%' in order to maintain size across platforms.
Forget what I said about end_render/begin_render. Just noticed the !is_interactive bits. Guess it may be necessary
Still working on an approach like my patch above - it's not working that well yet partly because of lack of information about Pango (or cause I can't wrap my head around it). Anyway accumulating information bits : PangoFT2 Fontmap Leak: http://bugzilla.gnome.org/show_bug.cgi?id=143542 Re: Pango Font Scaling http://mail.gnome.org/archives/gtk-i18n-list/2004-August/msg00008.html ... but not linear (as expected;)) : http://mail.gnome.org/archives/gtk-i18n-list/2004-August/msg00012.html Re: font size and point->pixel conversion (^= 72/96) http://mail.gnome.org/archives/gtk-i18n-list/2004-August/msg00029.html PangoRenderer (maybe the solution but not available for Pango/win32 yet) http://mail.gnome.org/archives/gtk-i18n-list/2004-July/msg00014.html Logical and Ink Rect http://mail.gnome.org/archives/gtk-devel-list/2001-August/msg00325.html Specifying font size in pixels (broken for win32?) http://bugzilla.gnome.org/show_bug.cgi?id=119081 http://people.redhat.com/otaylor/grid-fitting/ (found through: Adjusting width of rendered string) http://mail.gnome.org/archives/gtk-i18n-list/2003-August/msg00017.html
Also see Owens answer to my post http://mail.gnome.org/archives/gtk-i18n-list/2005-March/msg00006.html I haven't tried using it yet, as I don't know how to count graphemes in a string.
I'm thinking that for this to really work well, we'd need to store the string widths with the objects. That'll avoid the problem of strings changing size when switching to another OS, another build or another set of installed fonts. Only when the string is actually edited should the string width change, otherwise it should be the one that rendering scales to. This again is part of the text eidting makeover, as we'd need strings to be actual text objects rather than things that the objects render. So not a thing for 0.95, though a better scaling may be.
IMO this issue has nothing to do with editing facilities, or at least these things should be mostly independent. Or if you mean wih editing the ability to squeeze (make them resizable in themselve) strings I agree. For the monent I see it more as a general font handling improvement. - User selects a font size in points! -> The diagram updates it's text related bounding boxes based on that font/string size, regardless of the current scale of the diagram -> If after loading (even on a different platform) the font is the same it should not produce different sizes - or there is something screwed with the font backend (usage). What I'm planning to do (or already have done in my local tree) : - Make lib/font.c use *one* PangoContext used in all of Dia for string length measuring. - Make all dia_font_*() - !scaled finctions - use just that context to layout strings directly - Make all dia_font_scaled_*() just calculate the desired transformation based on the not scaled versions - Get rid of dia_font_*build_layout() functions in lib/font.[hc] - Implement DiaRenderer::create_layout() for all renderers which are using PangoLayout to output text. This goes along with DiaRenderer::set_context() i.e. *renderer specific* PangoContext. The latter will allow Dia to use the right (backend specific) PangoContext where appropriate and match string width to the default sizes. If done right this should also speed up the measuring process cause there won't be any continous tweaking in any dia_font_*() function. The only place where tweaking (probably) needs to take place is the actual drawing of the layout. With this infrastructure change it should be possible to use pango_context_set_matrix() to even have rotated or really 'squeezed' text ... I agree that the full thing isn't feasible for 0.95 cause at the moment it seems that there are some issues in Pango resolved to make all this possible. At least the win32 part is lacking some implementation e.g. PangoRenderer, but I also suspect bugs in pango_win32_render_transformed(). But if noone is going to report them they wont be fixed either :-)
I do seem to have found a usable approach, namely tweaking the sizes in the PangoGlyphString structure (on the PangoGlyphGeometry level) to scale linearly. One problem is that Pango rounds these sizes to pixels, so there's cumulative rounding errors. Current CVS has that implemented for freetype-based gdk renderer and latin-1 postscript renderer. The whole process was made a lot easier by wrapping the string, font and height together in TextLine, allowing for a place to store the sizes. Even creating TextLine objects in text_draw is way faster and more accurate than using the *scaled* framework.
This works very nicely for ensuring that zoom widths are the same. No good ideas for keeping widths across platforms, though.
Keeping this open for reference- but wont change anything atm.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dia/issues/124.