Re: script or block detection needed for Unicode fonts
On Saturday, September 28, 2002, at 03:19 PM, David Starner wrote: > On Sat, Sep 28, 2002 at 01:19:58PM -0700, Murray Sargent wrote: >> Michael Everson said: >>> I don't understand why a particular bit has to be set in >>> some table. Why can't the OS just accept what's in the font? >> >> The main reason is performance. If an application has to check the >> font >> cmap for every character in a file, it slows down reading the file. > > Try, for example, opening a file for which you have no font coverage in > Mozilla on Linux. It will open every font on the system looking for the > missing characters, and it will take quite a while, accompanied by much > disk thrashing to find they aren't there. > This just seems wildly inefficient to me, but then I'm coming from an OS where this isn't done. The app doesn't keep track of whether or not a particular font can draw a particular character; that's handled at display time. If a particular font doesn't handle a particular character, then a fallback mechanism is invoked by the system, which caches the necessary data. I really don't see why an application needs to check every character as it reads in a file to make sure it can be drawn with the set font. == John H. Jenkins [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.tejat.net/
Re: glyph selection for Unicode in browsers
Peter Constable wrote, > >Once the font specs for all this are set and fonts are released with > >the necessary coverage and the shaping engines can access all of this, > >the browsers are sure to quickly add support, too. > > I'm not quite as optimistic in terms of how close we are to having all this > ready to go. I think there's some hard work still ahead. > Oh, certainly. There's always hard work still ahead, it seems. A possible option for dealing with language specific font selection would be to enhance the user font preference options in browsers to include "lang" font assignments under the existing script assignments. To assist users in setting up such preferences, perhaps some kind of font information registry could be collected and published in order to avoid the duplication of effort which would be required if every user had to separately contact the various font developers asking about language suitability. I'd expect this kind of user preference option to be under "advanced" settings... Or, perhaps this degree of font selection could be handled at the HTML/XML authoring tool level. In other words, an author could set up "lang" tag preferences once, and then the tool could automatically set up CSS with appropriate font selection information based upon the "lang" tags used in the document. Or, the browser folks themselves could maintain an internal listing of "lang" tags and suitable fonts and apply them invisibly as default if no other font is selected. Of course, this still would mean much hard work ahead, but it would shift the burden from OpenType developers to browser developers. (smile) Best regards, James Kass.
Re: glyph selection for Unicode in browsers
Quoting [EMAIL PROTECTED]: > But should there not be some (possibly user-overridable) relationship > between an NLS or similar tag (e.g. "lang" in HTML or xml:lang) and one of > these so that a browser or word-processing app that knows what "language" > (e.g. what RFC 3066 tag) is applied to the data can tell the > layout/rendering sub-system what OT "language-system" tags to apply > (assuming some API exists to do so)? Surely that is where we want to move > toward. I think the idea is that, in a word processor for example, something like 'Typographic system' would be set by the user as an independent layout control, not directly linked to 'language'. This enables the user to select a language to use for sorting, spellchecking, etc. (character level text handling), and separately select a set of typographic conventions (glyph level text display). I suppose some developers may choose to pursue the direction you suggest, e.g. relating default typographic conventions to the user's language setting. I just make the fonts :) John Hudson
Re: script or block detection needed for Unicode fonts
John H. Jenkins scripsit: > This just seems wildly inefficient to me, but then I'm coming from an > OS where this isn't done. As a cross-platform app, Mozilla can't count on very much from the platform. -- John Cowan [EMAIL PROTECTED] http://www.reutershealth.com "Mr. Lane, if you ever wish anything that I can do all you will have to do will be to send me a telegram asking and it will be done." "Mr. Hearst, if you ever get a telegram from me asking you to do anything you can put the telegram down as a forgery."
RE: script or block detection needed for Unicode fonts
Title: Re: script or block detection needed for Unicode fonts John Jenkins wrote: "This just seems wildly inefficient to me, but then I'm coming from anOS where this isn't done. The app doesn't keep track of whether or nota particular font can draw a particular character; that's handled atdisplay time. If a particular font doesn't handle a particularcharacter, then a fallback mechanism is invoked by the system, whichcaches the necessary data. I really don't see why an application needsto check every character as it reads in a file to make sure it can bedrawn with the set font." Sigh. If I only had an OS like that to work with! There is the ransom-note effect though. Do you try to match the desired font characteristics? I should note that Windows XP does have limited "font linking" support as well, which works with system fonts. Unfortunately, system fonts have limited typographical appeal, so the missing-character/glyph problem is usually the responsibility of the application. Murray
OT: :lang pseudo-class support (was glyph selection....)
On Mon, 30 Sep 2002, Andrew Cunningham wrote: > Jungshik Shin wrote: > > On Fri, 27 Sep 2002 [EMAIL PROTECTED] wrote: > >>On 09/26/2002 10:46:42 PM Andrew Cunningham wrote: > >>>For me, this is the crux: that browsers have not implimented the css > >>>:lang selector. > > As I wrote in my response to Tex, css 'lang' pseudo-class is > > honored by MS IE and Mozilla 1.x/Netscape 7. > > > > Just tried the CSS2 'lang' pseudo-class just then in a test page in > mozilla 1.0, IE6 and opera 6.04. None of these browsers actually used > any of the css attributes I applied to the lang selector. > > The lang selector is obviously used in the browsers font linking, but > doesn't appear to have been used as a CSS selector. Thank you for pointing this out. You're absolutely right. I'm sorry I was mistaken. Mozilla has a bug filed for it at http://bugzilla.mozilla.org/show_bug.cgi?id=75374. I put up a couple of simple test pages at http://jshin.net/moztest/lang.pseudo.html http://jshin.net/moztest/lang.pseudo2.html Jungshik
