On Sat, 2004-12-04 at 15:49 +0000, Daniel Glassey wrote: > On Fri, 2004-12-03 at 13:42 -0500, Owen Taylor wrote: > > On Fri, 2004-12-03 at 13:07 -0500, Edward H. Trager wrote: > > > > Also what about Burmese? Is anyone working on Burmese via > > > OpenType, or does Burmese really require SIL's Graphite, and if > > > so is anybody seriously working on SIL integration into Pango? > > > > I think it should be quite possible to do Burmese with OpenType, > > I'm not aware of anybody working on that, or on Pango support > > for Burmese OpenType fonts. > > > > For Graphite support, see: > > > > http://bugzilla.gnome.org/show_bug.cgi?id=135697 > > Current progress is that it renders fine so it is suitable for UI > interfaces but line breaking, cursor tracking, selection are works in > progress. I'm a little surprised these aren't working ... this stuff is almost all handled at the layers above the shaper. About the only thing I can think of that would cause problems is if the shaper isn't setting the log_clusters array properly. > The module can be found in graphite cvs > https://sourceforge.net/cvs/?group_id=66144 in the directory > contrib/pangomod. The module also requires a patch to fontconfig > (https://bugs.freedesktop.org/show_bug.cgi?id=105) but I think it should > be possible to make that optional so it doesn't have to wait on that > patch as well. > > > There are some unresolved issues with font selection that make > > this unlikely for Pango-1.8.0. > > Hi Owen. Is there anything I can do to help resolve these. Can you > summarise what needs resolved please? Well, the unresolved issue to me is the whole question of font and shaper selection... there is a reasonable idea of what we want the end behavior to be: - If the user specifies a font that some shaper can use to render the text, then we should use that font and shaper. - If the specified font can't be used to render the script, we should go through all the fonts on the system (ordered by the normal fontconfig mechanisms like language coverage) and use the first one that can render the text with some shaper, with that shaper. But how to implement? The covers() mechanism that I added in Pango-1.4 was a failure because it didn't take the "pruning" that is done by fontconfig into account. If the "best" font on the system for rendering Burmese is FreeSans, fontconfig won't give us any more fonts after that. I think the pieces of a solution go something like: - Pango needs to not use fontconfig's pruning, and instead do get back the unpruned results from fontconfig and prune itself. (This also allows fixing some other problems like being able to filter out bitmap fonts) - pango.modules needs a capability for backend specific extension, so we can say maybe arabic:*:(otlayout:gsub) for "I can handle arabic for any language, but I need the GSUB opentype table". - There needs to be a way for the fontconfig backend to iterate through the set of available modules and collect that extra capability information to use to prune the results it gets back from fontconfig. - We probably need a way to pass script information in when creating a fontset, since we can't always reverse engineer language tag from script. (For Han, we use 'xx' for a language tag if no Han language tag was given explicitely.) That should allow implementing the behavior I described above. Then beyond that, there is the corner case of fonts that can be handled by multiple backends. The case where Graphite adds mark placement to a Latin font is reasonably easy to handle with the heuristic that if we have latin:* and latin:*:(<capabilities>) then we use the shaper that specifies capabilities for fonts with those capabilities. I don't know if there's any way to handle the case of a font with both OpenType and Graphite tables for the same font. Picking one shaper or the other basically randomly is really all we can do. What I don't want to do is add config options. I'd like things to work out of the box; if you have a font, and you have a shaper that can handle that font, you should be able to use that font. I hope that gives some idea of where my thinking is. None of the above is incredibly complex to implement, but there are a lot of pieces that have to be fitted together. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part