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/ _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts