From: Thomas Lotze (thomas.lotze@uni-jena.de)
Date: Thu Nov 07 2002 - 20:18:08 EST
On Thu, 7 Nov 2002 16:57:04 -0600
Peter_Constable@sil.org wrote:
> >> As for providing a
> >> notification dialog to say that the text contains < c, ZWJ, t > but
> >> that the font doesn't support it, there are no existing mechanisms
> >> to support that at present,
> Sure, if you're writing software that interprets OT lookups, you could
> do this. If you want to write your own code to process that state
> tables in AAT or Graphite fonts, you could do this. The software that
> currently do these thing and that most app developers are going to
> rely on do not.
OK. I had read your earlier statement to the effect that it would be
impossible in principle. But if the mechanisms that are missing are
"just" the implementations, I can see your point.
> In a typesetting application, you would be immediately informed: you
> see it in your proof, or you do not. If it's not there, you act
> accordingly.
[...]
> But if you're an author wanting a ligature, you don't need to proof
> read the entire long document; you just enter one instance and check
> it, and you'll known right away what the results for the rest of the
> document will be.
Depends on how the system works. If it's a thing where you get to see
the result while typing, this is true to a certain degree. If it's a
system working like, say, TeX that produces a typeset document (PDF etc)
from a marked-up text input (a TeX file, XML, etc), it's a different
matter.
But even if you see the outcome as you're typing, you might decide to
apply a different font to the whole document later on, or change
something similar. Obviously you wouldn't want to retype it all just to
see it comes out right this time, and it would even be a stupid and
error-prone task to try out all the ligatures etc again after each
change.
Cheers, Thomas
-- Thomas Lotze thomas.lotze@gmx.net http://www.thomas-lotze.de/
This archive was generated by hypermail 2.1.5 : Thu Nov 07 2002 - 20:52:53 EST