Re: Pango-1.7.0 released [unstable]



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]