From: Antoine Leca (Antoine10646@leca-marti.org)
Date: Thu Mar 23 2006 - 04:09:28 CST
Philippe Verdy wrote:
> I really spoke about OpenType whose most important
> standard addition if the substitution and positioning tables.
>
> To implement those tables, you don't necessarily need to have a
> stable set of rules, simplied in standard "feature" tables.
Agreed. One of the most important specificity of OpenType is that the use of
the table datas relies on the "application software".
However there is a little problem in the middle of the road.
Except some very specific cases (like OTLS or ADK), the tables are not
easily accessible from user application software, while they are pretty
easily available for system softwares. Those softwares (Uniscribe, ICU
LayoutEngine, Pango) are really applications when seen from the main drawing
engine (GDI, whatever, X11 or Freetype, respectively), but their behaviour
as seen by normal developpers or plain users is those of a system software.
Furthermore, to ensure interoperability (a very desired feature), one has to
casts some rules in stone. It was decided to use the TrueTypeOpen
architecture for complex script layout. The result is that those system
software sort-of take precedence over the use of the OpenType tables, in the
case of complex scripts.
Sure you can go the same road again and reinvent the same wheel to render
complex scripts; Graphite does about exactly that, so I believe Peter is
qualified to explain in much more details how complex it can be.
You can even use the OpenType architecture for that use (my guess is that
other developpers did avoid it to avoid IP battles with Microsoft; as well
as the not-invented-here syndrom.) It certainly would work somewhat, at the
end of the day.
I am not sure it would be definitively better.
I am just sure it would NOT be interoperable; that means, *no font* to begin
with. So your chance of having many users, at this point of the history, are
pretty thin.
The decision to use TTO for complex scripts is dated 1994 ± 1.
> Just common tables, out of any "feature", would do the trick,
> without requiring special interpretation according to the script
> or feature label in the opentype font, implemented in the text
> renderer.
Well, no.
Just have a look at GX solution _and implementations_ for the problem of
reordering should give you a hint that it is NOT easy. (Yes Dave/John, it
*is* elegant.)
Since OpenType is a bit less rich in functionnality here: it cannot easily
specify a reorder involving four glyphs, with ignored context in the middle,
for instance (and here I am ignoring the fact that the font construction
tools, like VOLT, are even one or several step back); the resulting solution
will be /quite/ heavy. I remember reading MS engineers (think it should be
S.M.) talking about some tries they did along this way, performances were
awful, the engine was really spending all the machine time interpreting
numerous OpenType lookups.
It is not efficient. And the resulting tables are real bloat (also, it
exceeded the 16-bit limit of TTO ;-).)
Flexible and elegant, but inefficient.
Artistic, but not industrial.
> As long as there's a standard OpenType renderer, it would work even
> in absence ofspecific support for the script in the renderer: the
> renderer just has to use the subst/posn tables asthey are implemented
> in the font,and the renderer does not ned to infer more complete
> tables from a reduced set of rules encoded in a feature.
That is almost exactly the GX/AAT way.
Read about the war between OT and GX in the years 1994-96, it is full of
arguments one way or the other.
But the war is over.
> Of course this means that this single feature in the font will
> not be under control of the application.
Why not? Every OpenType-enable application is, at the very least, able to
slect the "feature" it want to be applied or not (and most "real" ones give
the user a hand to it). Just unselect your "Indic rendering" features, and
you are done. No mess done, the application can do it itself.
Which is what Charmap should have done in the first place.
Perhaps, one can toggle this feature, defining ETO_IGNORELANGUAGE as the way
to unselect this feature...
> So the applicationfor example will not be able to
> control whever ligatures should be honored, or if language-specific
> rules or subsets of ligatures should be enabled, replaced, or
Just design a number of features to do each and every of these tasks, make
them enable by default, and you are done.
By the way, an application which does Indic rendering (like Uniscribe, or
more to the point ICU LayoutEngine) is free to decide to apply, or not, the
"optional" steps (like most conjunct formation).
The problem if we go this road, is that we should add a number of feature to
the renderers, and performances will suffer.
But it could be a good improvement in the future.
By the way, it is very easy to enforce this idea: just design those
optionnal features, register them, and talk to MichKa, Peter, and his team
to have Uniscribe use them or giving some API way to enable them. Job done.
Released operationaly in 2010, world-wide (ex-Blackcomb, now Vienna.)
> When you say that Idon't knowwhat I'm speaking about, it'sjust that I
> don't use your terminology, or do not participate to OpenType
> standardisation group.
I am not sure. The excerpt you gave about Indic rendering is so much an
oversimplification of the process, that it certainly has a real theoric
interest, but it fails to address the real scale of the problem.
And the scale of the problem is exactly what triggers the use of "fixed
reorderding rules in the renderer" in the first place (which is the very
point you are fighting.)
I hope you did make the effort to read al this stance. I thank you at this
point for having done so. I expect you to try to answer as a whole, not on
specific points taken out of context.
Antoine
This archive was generated by hypermail 2.1.5 : Thu Mar 23 2006 - 04:25:22 CST