[Devel] Re: [Fonts]Another approach to text in X

[Vadim Plessky]

On Sunday 23 December 2001 20:17, Keith Packard wrote:
|   Around 11 o'clock on Dec 23, David Turner wrote:
|
|   But, it looks like UniType has some additional features:
|   >      - identify each installed/available "face" with a _unique_
|   >        and _persistent_ 128-bit signature.
|
|   This seems like it will be useful in transmitting precise face names from
|   one application to another, but I'm afraid that font versioning will make
|   it less useful in transmitting face names from one machine to another. 
| Is there some reason not to trust the font identification built into the
| files as usefully unique?

Hi Keith!

You have mentioned that your solution is "Independent of output technology or 
rasterization; it's just a configuration, customization and matching library"
How you deal with kerning in it?
It's quite common in Publishing Industry when you update your AFM file (which 
complement PFB - PS Type1 font) say, once per year or even more often.
Reason: new kerning values, or updated kerning values.

It seems that you need to store Kerning information in each word processor 
document (when word processor, like KWord, operates in DTP mode, I am not 
speaking about plain text here) - even when you decided *do not embed* fonts.
Reason: if you make font substitution, and change to another typeface, most 
likely all formatting information will be lost.
Of course this should be stored in some XML format (like part of KWord 
document, or in XML with some completely new DTD)

It would be nice to hear both from you and David Turner (and from Sun/Alan 
Coopersmith, of course) how "transmitting face names" will work and how you 
can prevent loosing of formatting info (missing kerning, tracking) in this 
case? 
It wil be very nice if text layouting & font identification in X gets a boost 
(either with UniType, or with Keith's work, or with ST) but I am pretty much 
concerned how it wil affect (or improove) existing applications.

|
|   My plan for 'fontconfig' was to use the names in the files and allow the
|   application to discover how close the requested pattern was to the actual
|   matched face.  That way the application can discover whether the face
|   names and styles matched, or whether some substitution was made.
|
|   >          * languages _really_ supported by the face (answering this
|   >            question is hard !!)
|
|   I agree it's pretty hard, but I don't know if it's really needed.
|   Applications need to find a face which covers a reasonable portion of the
|   document, and then they need to find faces which can fill-in the missing
|   pieces, and which match the other faces reasonably well.  Owen Taylor and
|   I talked about this at ALS and I think we've figured out a mechanism that
|   will work with upper level libraries in a reasonably efficient way.
|
|   The idea is to list all of the available faces in 'match' order -- the
|   distance from the face to the requested pattern.  Now this list can be

How you are going to measure distance?
It can be VERY difficult.
And most likely this wil give platform-dependant results.
 There was discussion (I guees, on FT mailing list) about using HStem and 
VStem values for font identification, but IIRC several people were opposing 
this.
Still I think that can be good, as it wil be inline with CSS3:Fonts module 
(where you can use HStem and VStem values for font matching)

|   searched to find a face containing any desired set of glyphs.  Using a
|   persistant list built when the font was requested ensures that the order
|   is "stable" -- independent of the order in which glyphs are requested.
|
[...]
|
|   Keith Packard        XFree86 Core Team        Compaq Cambridge Research
| Lab

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/