[Bug 158573] <Tradition Chinese Font are different.
https://bugzilla.novell.com/show_bug.cgi?id=158573 david@freetype.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@freetype.org ------- Comment #37 from david@freetype.org 2006-10-18 02:42 MST ------- Hello everyone, I'm pretty new here, but I'd like to make a few statements. First of all, the TrueType specification clearly wasn't designed with easy emboldening in mind, since it explicitely allows: - two contours to intersect (note: this is note the same than a single self-intersecting contour). See http://developer.apple.com/textfonts/TTRefMan/RM01/Chap1.html#intersecting - contours in arbitrary drawing directions, see the graphics in: http://developer.apple.com/textfonts/TTRefMan/RM02/Chap2.html#distinguishing note that even if all contours are oriented uniformly, you could have a reversal of the drawing direction in a composite glyph using, for example a mirroring transform (i've seen this implemented in a font to generate the reversed cyrillic R, for example) this is a lot less strict than the Postscript font design rules, which allow the emboldening algorithm to work flawlessly for any compliant font. Generally speaking, the current algorithm tries to do its job very quickly by simply "displacing" the glyph outline towards the "exterior" direction. It is quick because it doesn't try to compute new points in the outline, or see if there are intersections. And it works well in a *lot* of cases :-) it simply assumes that the glyph is wel-formed, computes its orientation, then apply the relevant displacements to all points. A general-purpose emboldening algorithm is something *very* different that must be capable of computing all intersections in the glyph (not only in each contour), and tesselate the result appropriately when these are found. This involves a lot of complex mathematics, with very subtle and hard-to-fix rounding issues; while it is possible to implement something like this, its performance will most certainly suck (witness the performance of the Cairo tesselators, where the original one is a drag and the new "optimized" one only provides massive speed-ups in complex/theorical cases, while being slower in practical ones at the moment; all this means is that writing an efficient tesselator is *hard* stuff). And consider that what we need here is considerably more difficult than what is used in Cairo, since we need to deal with Bezier arcs, not only line segments. in an ideal world, we should be able to quickly determine if a glyph is well-formed, and use the short-cut when this is the case. When note, we should be able to use the slow algorithm (when and if it exists). however, I'm for a more practical approach at the moment. I'll try to submit a patch that will do the following: - to compute the global orientation, try to compute the orientation of all 4 borders of the glyph (top/bottom/left/right) - if they all match, return the corresponding value - if only 3 of them match, return their value since it probably means a self-intersecting gizmo like the one in the FZSongTi.ttf - the only alternative is where we have 2 opposite values in equal numbers (2+2), in this case, we have a problem, and do *nothing*, at least we'll have something nicer to display. what do you think about it ? It's only a slightly refined heuristic that doesn't force us to actually compute overlaps/intersections, but I hope it should be enough for the curious cases we're seeing. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
participants (1)
-
bugzilla_noreply@novell.com