Re: [Fonts]edit antialias=false equivalent in fonts.conf
Ken Deeter (Kentarou SHINOHARA) wrote: ... Hmm.. i'm not sure this would be so helpful for kanji characters since often two parallel one-pixel width lines will be one pixel apart. Any grayness in between will just make things look really smudged. I have very similar concerns for scaling Kanji bitmaps in mozilla but the Japanese and Chinese useres I've talked to report that they really like it and I have not had any negative reports. Also see chapter 2 of the Truetype spec: http://www.microsoft.com/typography/tt/tt.htm EBSC - Embedded Bitmap Scaling Table The EBSC table provides a mechanism for describing embedded bitmaps which are created by scaling other embedded bitmaps. While this is the sort of thing that outline font technologies were invented to avoid, there are cases (small sizes of Kanji, for example) where scaling a bitmap produces a more legible font than scan-converting an outline. For this reason the EBSC table allows a font to define a bitmap strike as a scaled version of another strike. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
Keith Packard wrote: ... He suggested both -- combining multiple sizes in a single font and combining multiple styles into a single .ttc file. I've seen a few fonts distributed in this fashion; in particular, the GB2312 version of SimSun has two fonts in one file, a proportional and monospaced version of the same face. My understanding is that Truetype collections (TTC) were invented to solve that specific problem: not having to ship two versions of a CJK font; one with monospaced Latin glyphs and one with proportional Latin glyphs. Since the Kanji data can be quite large (multiple megabytes) and the Latin glyphs are relatively small (100s of kilobytes) this can save disk space for CJK users. I do not recall ever seeing other style differences mixed in a TTC font which would make me cautious about doing this in TTC. In contrast, Adobe Multiple Masters are specifically designed to support different styles in one font and allow the font renderer to select any percentage of either. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]enquiry about pcf/bdf font support
Keith Packard wrote: ... FreeType doesn't (yet) support compressed PCF fonts. I've since had a revelation that we should discard PCF font files and replace them with TTF files containing an embedded bitmap. Very interesting idea! If anyone has experience writing TrueType font files, help would be greatly appreciated in building something that can create these new files. The printing code in OpenOffice has C code to pull apart a TrueType font and recompose a subset. It does not handle ebmedded bitmaps. Ghostscript also has C code to parse TrueType fonts. I also have a bit of perl that takes TrueType fonts apart so I can inspect them. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Can I test for the sub-pixel rendering function ?
Vadim Plessky wrote: On Friday 02 August 2002 1:25 pm, Zenith Lau wrote: ... | Last question, the value for rgba, is [rgb | bgr | vrgb | vbgr], does all | this is for sub-pixel rendering ? I know that, rgb or bgr is the seq for | the Red, Green, and Blue position, but how about the 'v' stand for?? The v stands for vertical. Typically the 3 LCDs per pixel are layed out horizontally. This means that when generating the alpha mask the code generates the mask at the desired height but 3x the normal width. For vertical the code generates the mask with the desired (or implied) width and 3x the desired height. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Pablo Saratxaga wrote: ... On Thu, Jul 18, 2002 at 10:12:05AM -0700, Keith Packard wrote: Around 13 o'clock on Jul 18, Pablo Saratxaga wrote: In other terms, the localized names are used to display in the lists shown to the user, when when one of those is choosen, what is returned is not the localized name but the ascii-only one. And inversly, when an ascii-only name is gotten, it should be possible to retrieve its associated localized name if needed. Why do you believe the internal interface should only use ASCII names? Not necessarly ASCII names, but unique and locale independent ones. So if a document which embedds fotn names is open under a different locale nothing strange happens. Yes, this is important. I can well imagine an app that that saves a user's preference. If the user changes locale then the saved preferences should still find the user's previously set prefered fonts. I expect this to mean that the app will save the preferences in ascii and then get the localized list for display. Note that *all* of these names are locale independent; applications can use any of the names to access the font, the only question is what name should be returned when the application requests it, the mapping from the set of names to a name appropriate for the user is the only locale -dependent step. Will there be a way to get the localized name using the ascii only name? Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Keith Packard wrote: ... A naïve application using the existing FcPatternGetString API will get an English name for each font. Wouldn't it make more sense for a naive app to get the localized name? Thus apps users of simple apps would get names they could read; eg: Japanese users by default get Japanese names, Greek users would get Greek names, and so forth. a) Store just the English name. To make the code regular for all languages I would really prefer to store the ascii only name and then always get the localized names for display. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Pablo Saratxaga wrote: ... On Sat, Jul 13, 2002 at 10:40:51AM -0700, Keith Packard wrote: I'd be interested to hear whether other people will find this scheme usable, and whether people would also like to see the other localized names made available for presentation to the user. Yes, both localized names and ascii-only names are usefull. Maybe the same api could be used for both cases, trough a paremeter telling which localized language is requested (if C, then ascii-only names are given). The availability of localized names will make users feel more comfortable, as other systems will display those names to them. Yes, being able to read localized font names greatly improves the ability of non-English readers to select fonts. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Unicode coverage for languages
Keith Packard wrote: ... currently, the font database is computed solely from the fonts themselves I think Yao makes an interesting point: it might be good to have some additional information besides what is in the fonts themselves. This could certainly help us approach the problem of determining which languages a font is suitable for. It would be attractive if this information could be easily upgraded over time (read: automatically upgraded) as new fonts came out (or as old fonts were categorized). Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [I18n]Unicode coverage for languages
Yao Zhang wrote: ... The only way to find out which Han variant one font has is by looking at it. When you say looking at it do you mean actually having a human view the glyphs? As long as we can configure it properly, zh_CN, zh_HK and zh_TW etc really do not matter. What do you mean by As long as we can configure it properly? -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]language tags in fontconfig
Keith Packard wrote: I'm currently using a (bogus) set of language names in fontconfig. FC_LANG values are intended to solve two separate problems: 1) Identifying Han fonts with appropriate glyph shapes 2) Identifying fonts likely to hold all of the glyphs needed for a document. Clearly LANG is a misnomer here -- it's not language we're interested in, it's the character set. In particular, ISO 639 doesn't distinguish between simplified chinese and traditional chinese. So, we need to stir in the country code as well, much as one would when setting a locale name. I hate to promote the horrid ANSI-C locale model, but I don't see a great deal of choice here. The OpenType/TrueType spec has been actively in use for a while http://www.microsoft.com/typography/otspec/os2.htm#cpr and certainly hints at a set of languages. Seeing as many web pages are designed on/for Microsoft Windows systems it seems likely that many web pages will implicitly use these language sets. In addition, I'm thinking of automatically adding information from the current locale to font patterns which don't specify a lang value. With the new strong/weak FC_FAMILY bindings, this means that generic family names will now match a locale-specific face, which seems like the right plan. This seems reasonable. If a Japanese user wanted the ASCII text in Helvetica and the Japanese text in Mincho how would they specify this? Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font matching with generic family names and language groups
Keith Packard wrote: Around 9 o'clock on Jun 28, Brian Stell wrote: For Mozilla I add the family + language-group as this seems the closest match. The family (any-language-group) was added when I observed that some X fonts cover larger code sets by subsetting a larger font; eg: This is (fortunately) not a significant problem with client-side fonts; Yes, I have only seen this as an issue for X server side font. Still, does the FontConfig code handle server side fonts? I have primarily seen this in use for Japanese users who want to be able to specify the fonts used for JISX0201 and JISX0212. Hmm. I have less experience (oddly) with these encodings; are there generally separate TrueType files for these? I have only seen this for X server side fonts. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Xft and MathML [Was: [Fonts]Xft for OpenGL]
Keith Packard wrote: ... I'd like someone with a real understanding of how MathML is supposed to work Do you know Roger Sidje? Roger B. Sidje [EMAIL PROTECTED] Have you seen this page: http://www.mozilla.org/projects/mathml/ to lead me through how Xft and fontconfig could help Mozilla display MathML pages better. The current non-Xft MathML support is far from perfect; it knows the encoding of a select set of fonts and if you have different ones, you get incorrect glyphs on the screen. Displaying the wrong glyph is never reasonable, I'd like to figure out how to make it either display the right glyph or let the user know that no such glyph is available. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Xft for OpenGL
Does Xft build/work under OpenGL? -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Yao Zhang wrote: ... But in my opinion, combining different Chinese fonts together to get a bigger coverage is generally not a good idea. I see this kind of thing happens in Mozilla, GTK+ 2. When I see it, the only effect is that it tells me I should change my font settings, the same as I see undisplayable, square substitute showing on my screen. So why go through all the trouble to implement something no one will like. Current fonts each tend to cover one language and *English*. One of the main intents of larger code coverage is to allow documents to have two or more languages where none of them is English. For example, what font setting could you pick if the document had: Traditional Chinese and Cyrillic Simplified Chinese and Thai Korean and Japanese Portuguese and Devanagari Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Owen Taylor wrote: ... Pango already has the language tagging mechanism; the question is how to use this to influence character lookup. a) Call FcFontSetSort() once, get a list, and then when finding a (language-tag, codepoint) pair, look first for a font with the language tag and the codepoint, then if that fails, look for a font without the language tag with the codepoint. Problems: - ... - I don't think we should ever fall back to a font that wasn't explicitely specified (*), just for a want of a language tag. Please forgive me if I'm being slow but due to the triple negative I am not clear what the last statement means (I did read the footnote). Does this say we should not try to find a fallback font if we do not have a language tag? Or perhaps does this say we should not look at fallback fonts where the language for the font is not specified? Or perhaps does this mean that we should not fallback to a font that was not specified just because we do not have a language tag? Would you kindly expound on this? Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Scaled bitmap fonts
Keith Packard wrote: Around 14 o'clock on May 8, Owen Taylor wrote: But this use is ruined if FreeType starts reporting bitmap fonts as scaleable fonts and starts scaling then. (It would be really unfortunate if FreeType replicated the X core situation where software needs to play tricks to determine if a scaleable font is a real scaleable font or a jaggied bitmap.) No, my idea was to have FreeType continue to report bitmap fonts with their natural size so that applications could separate fact from fiction. The change would be to add a way for applications to take a specific bitmap and request that it be rescaled to a new size, either with the existing transformation API, or possibly with a new API. This seems to me to be something that the application should have explicit control over. An API sounds like a good idea. It should be hard for applications to get scaled bitmaps, I certainly never want to see them on my screen, even if they're filtered. I've not had any trouble downloading TT fonts for every language I've wanted to view. When I first had the idea of anti-aliased scaled bitmaps I assumed they would only be a fallback or second choice. I saw them as a way to get intermediate sizes so Unix/Linux web layout would better be able to mirror Mac/Windows layout. Surprisingly I found the CJK users actually liked them. I later found this in chapter 2 of the TrueType spec: EBSC - Embedded Bitmap Scaling Table While this is the sort of thing that outline font technologies were invented to avoid, there are cases (small sizes of Kanji, for example) where scaling a bitmap produces a more legible font than scan-converting an outline. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]TrueType Embedded bitmap?
Yu Shao wrote: ... Does any XFree's rasterizer, either freetype Please note that FreeType is not produced by the XFree86 team. FreeType is a separate library that XFree86 uses. For more info on FreeType see http://www.freetype.org/ Any idea on how to handle a truetype font with embedded bitmap data, although I believe it is not popular. I do see embbedded bitmaps in Japanese fonts such as MS-Mincho and HG-Gothic and they appear to me (non-Japanese reader) to be quite attractive compared to the outline rendered glyphs from the same fonts. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]GL and GR encodings
James A. Crippen wrote: ... See the comment about AIX and KS C 5601. Aren't you glad we're starting to move away from XLFD? :-) AAAGGG! I've always loved XLFD, really. It's so ... 'descriptive'. I've often found it lacks enough description. For example: What chars are supported in a iso10646 font? It seems very expensive to XQueryFont to get the per-char metrics so one can tell which chars are supported. How does one tell the language groups that a iso10646 font is appropriate for? How does one tell if a JISX0201 font is missing the ascii range? How would one tell if a TrueType font has embedded bitmaps and how does one choose the embedded bitmap vs the outline? How does an app say to anti-alias a TrueType font vs not AA? (separately from embedded bitmaps) If XLFD is going away, what's the replacement? I'd guess that XLFD won't go away quickly. However I do believe that as TrueType fonts come in we will want to rethink how to get information about the available fonts and how to control what options are selected. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Complex text layout and mapping screen coordinates
Keith Packard wrote: ... APIs can change much faster than protocols; adding a new library requires changes only to the local system, not to every possible remote X server. nicely put If there were a way to easily upgrade all the X servers in the the field this would not be such a problem. Unfortunately it takes years for a new X server to be in wide spread use. Apps that want new font features this year (whatever the date) will need to handle them on the client side as Xft, Mozilla, and OpenOffice do. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Complex text layout and mapping screen coordinates
Arun Sharma wrote: ... - One of the primary justifications for client side fonts is the slow pace of X server development Slow deployment of new features is the issue not slow development. The XFree86 folks are doing a great job. The problem is that the cool new features take a long time to get on *all* (or at least a high percentage) desktops as users do not regularly upgrade their X servers unless they upgrade their OS. and the difficulty of supporting legacy X servers Supporting legacy X servers is fairly easy for client side font handling. For server side font handling the deployment of new X server extensions the issue is slow deployment of new X servers. Are these points a good basis to continue further discussion or do we have a significant number of people disagreeing with the above ? Differences noted above. To add some context to this discussion - it started out of a review of IndiX - http://rohini.ncst.ernet.in/indix/ - an effort to support Indian languages using XFree86. IndiX takes a server side font rendering approach. I'm glad to see people thinking about how to support Indian languages. When would most desktops see this new IndiX extension? I believe my goal is similar yours: move the X environment forward. I spent a fair amount of time discussing the deployment issue with Keith. The Xrender extension is very fast but for X servers without this extension it does not matter. Its good to see that Xft has addressed the deployment issue and can now can work on all X servers. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] Complex text layout and mapping screen coordinates
Keyur Shroff wrote: ... a separate request need to be sent for each character (or glyph?) code over the wire. I believe the Xrender extension allows a string to be sent in one request with individual x,y positions for each glyph so the data difference is small (ie: no packet header/trailer per char/glyph). Either way the amount of data is small compared to images. For me the data bandwidth seems minor compared to the fact that X server upgrades take years to get into the field. These great new features will be only be usable years after other systems have them. Technology seems to continue to evolve. It would be nice if X had a chance to be relatively current. Thus to me it seems better to keep the X server simple and put the complexity at the client. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Another approach to text in X
Alan Coopersmith wrote: ... It is our belief that leaving font rendering on the server side will be more efficient than sending the bits over from the client side. Have the fonts handled at the server means having to pull the metrics over the the client. Having the fonts handled at the client means having to send the glyph data over to the server. I looked at this and it did not seem dramatically different. Maybe slight more bytes for the client side. To me this pales in comparison to moving images which everyone is doing a lot these days. One place where server side would have an advantage is for sub pixel rendering. A sophisticated app might want to rerender each glyph to get the apperance of subpixel layout. This would give the best WYSIWYG screen display and allow better layout of the printed page. I had this working at one point in an experimental Mozilla build (this was not TrueType related) but I had to back it out because for it to work the layout layer would need to know the subpixel positions to correctly support highlighting. Changing the layout layer to know the subpixel values was not something I had time for at that point. We also think that having the text in the server may provide additional benefits, such as allowing accessibility solutions to access the text of clients who don't use an accessibility- enabled toolkit. I'm not familiar with this. Could you talk about this a bit more? We've tried to design the XST api so it can work either with a XST-enabled X server, or by directly linking with ST, on a non-XST enabled X server. This should allow us to test and see which approach is better in the long run, once we finish implementing both methods. It will be interesting to see you results. From my perspective one of the critical reasons to move to client side is that people don't change their X server very often so great new features in the X server take a long time to get into wide spread use in the field. Waiting for X server changes takes years. I'd like to see the X environment be a place where new features can move on to user's desktops in weeks or months. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Quick question on the BDF fonts
What happens when the iso10646 font does not have all the char/glyphs in a iso8859-x encoding? The strageties I can think of are: 1) produce a iso8859-x font with missing glyphs This seems likely to cause blank chars to be displayed. It's my impression that most X apps tend to assume that non-iso10646 X fonts have all the glyphs in the encoding and do not actually query the font for the valid glyph list. Without knowing the valid glyph list there is no way to fill in the missing glyphs from other fonts. 2) don't make the iso8859-x font Markus Kuhn wrote: Mike A. Harris wrote on 2002-02-04 08:27 UTC: Do I understand correctly that the xfs font server and also the Xserver can both now re-encode ISO10646 BDF fonts on the fly to the various ISO8859-* and other encodings? I don't think so. At the moment, we use the Perl script ucs2any in order to recorde the ISO10646-1 BDF files at font file installation time. If it does not do this currently, is anyone already working on it or planning to? Juliusz has though about it several times, and each time decided that he doesn't feel like doing it and that he got fed up with BDF/PCF. I'm not aware of any plans or progress here. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: http://www.cl.cam.ac.uk/~mgk25/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Quick question on the BDF fonts
Markus Kuhn wrote: ... BTW: While there is so much concern about completeness of X11 Unicode fonts here, I discovered yesterday that Netscape 6.2's PostScript printer driver has an extremely disappointing character coverage. I couldn't get it to print even a single non-ISO-8859-1 character, even though the standard PostScript fonts contain all characters needed for example to print for instance http://www.cl.cam.ac.uk/~mgk25/ucs/groff_char.txt (a simple UTF-8 file that lists all character that can currently appear in Linux man pages, even when printed on PostScript). Would you kindly open a bugzilla bug on this? I agree, Linux/Unix Mozilla printing needs work. I'm currently in the middle of a personal project to add TrueType to Postscript to Linux/Unix mozilla's printing. I plan to output Type11 fonts so this should support Unicode (Type11 == CID keyed TrueType embedded in Postscript). -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [I18n]Re: [Fonts]Another approach to text in X
David Turner wrote: ... I didn't find that Brian Stell was harsh in any way.. Announcements are great things, but Sun has a history of disappointing the Open Source community. I'm pretty certain that the ST team is good-hearted and talented, I simply fear Sun's management and the SCSL :o) Just to be clear: I have not made any statement on the goodness or not-goodness of this work or any previous work by Sun. I would like to see what they have done as the international features in the X environment primarily came out of an older era. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [I18n]Another approach to text in X
Alan Coopersmith wrote: Over the past few months, a team of Sun engineers with experience in X internals, internationalization, and fonts have been working on a proposed new text architecture for X. How does one find out more about this effort? -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [I18n]Another approach to text in X
Documentation please. Alan Coopersmith wrote: Over the past few months, a team of Sun engineers with experience in X internals, internationalization, and fonts have been working on a proposed new text architecture for X. We've all been watching the discussion of various font text problems and proposed solutions on mailing lists such as the XFree86 lists, but have had to keep quiet pending management approval to discuss our project openly. The Sun project was started because the current X font and text mechanisms are dated and do not meet the needs of globalized applications. We have designed a display and platform-independent text architecture, the Standard Type Services (ST) framework, which handles not just font rendering, but text layout and font management as well. ST incorporates typographically sophisticated features and ideas from the best regarded existing APIs, including Apple Type Services for Unicode Imaging (ATSUI) and Java2D TextLayouts. On top of ST, we have layered a new extension to the X protocol, called XST, which incorporates the ST functionality. The ST API will also be exposed to applications independant of the X environment so that it can be used for Java servlets and applets and text rendering to printers, image files, and other displays. The ST Framework provides a scalable client-server architecture that allows multiple clients to share access to common fonts, while allowing applications with private fonts to keep them private. ST provides a pluggable API through which many font scalers can be used by the Font Server, including handling of smart font technology such as OpenType TrueType GX. Plugins for several font scalers are available today, each providing a different set of capabilities, properties and licenses, but unified under a single API for the client. The ST API includes functions for font management, rendering, text layout, and access to all available information about the font, including access to outlines for output to vector devices. ST is designed around Unicode and support for languages requiring complex text layout is included as a core part of the design. We are preparing to release ST under a X/BSD-style license, and once that happens, we plan to work with the XFree86, X.org, and li18nux.org communities to make sure ST XST meet the needs of the widest audience. We will send a further announcement to these groups when the ST materials are released. - The ST Core Team: Alex Gelfenbain [EMAIL PROTECTED] Alan Coopersmith[EMAIL PROTECTED] Jay Cotton [EMAIL PROTECTED] Jay Hobson [EMAIL PROTECTED] Stuart Kreitman [EMAIL PROTECTED] X11 Globalization Technology Group Sun Microsystems, Inc. ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n -- Brian Stell mailto:[EMAIL PROTECTED] ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Re: [I18n]Another approach to text in X
Andrew C Aitchison wrote: Brian Stell wrote: Documentation please. Alan Coopersmith wrote: Over the past few months, a team of Sun engineers with experience in X internals, internationalization, and fonts have been working on a proposed new text architecture for X. We've all been watching the discussion of various font text problems and proposed solutions on mailing lists such as the XFree86 lists, but have had to keep quiet pending management approval to discuss our project openly. Brian, that it ungracious. Why would wanting more info on this be considered a problem? -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Render] Re: Removing core support from Xft
Steve Swales wrote: ... But every glyph would have to be sent over the wire as a pixmap, every time it's drawn. Performance would be so bad, particularly over the wire, that it would be as good as broken... or am I missing something? The glyph could be stored on the X server in a off screen pixmap. -- Brian Stell mailto:[EMAIL PROTECTED] ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Removing core support from Xft
Keith Packard wrote: ... Server-side fonts were added to Xft to support legacy X servers without the Render extension. I suggest that instead of using server-side fonts, Xft should rasterize glyphs with FreeType and draw with the Render extension where available and using the core protocol for legacy servers without Render support. I'd implement both AA and non-AA paths, making this perform reasonably well over networks while also providing extended capabilities for servers not able to move to the Render extension. I've done client-side non-AA text in the core protocol in the past and have found it acceptable, even over relatively low speed links (128K ISDN). This is great idea. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Xpert]Honest question about font complexity.
Keith Packard wrote: Around 13 o'clock on Dec 1, Brian Stell wrote: Okay, so you are describing the non-X case. How would X apps get notified? Via whatever mechanism we come up with for the non-X case. Seems like an odd perspective to consider the X side as an after thought (especially when the discussion is about fonts in a xfree86 mailing list). I would have expected that the design would be a X solution that had a method to also reach the non-X apps. For example, there could be a property on the root window that was the id of a separate font notification window. An app would use the root window property to get the second window id and then listen for events on that window. A helper app could forward the messages to some other IPC mechanism (such message queues) which the local non-X apps could could use. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Xpert]Honest question about font complexity.
Keith Packard wrote: Around 3 o'clock on Nov 30, Mike A. Harris wrote: Just as an example, would it make sense to have xfs automatically look at all the dirs in its config, and have mkfontdir/ttmkfdir/etc. code built in? That's pretty much what Xft does -- you *can* build a system-wide cache file in each font directory, but if you don't bother, Xft will manage with a per-user cache file in each home directory. So, with Xft, it really can be as simple as dropping fonts in a directory. Xft is a client side feature and runs in a user process with that user's privledges. How could Xft update a system wide resource unless the files/dirs were unprotected (world writable) or the user was root? If a user tells an application to download a font what API would the app use to add it to the font cache? When new fonts become available how do apps get informed of this? -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: [Xpert]Honest question about font complexity.
Keith Packard wrote: ... When new fonts become available how do apps get informed of this? There is no current mechanism for this, and there are a couple of questions to be answered before we can design one: + What basic signalling mechanism should be used Probably a property event off the root window. + Who has permission to signal apps Is this an issue if property events are used? If a font in added (eg: downloaded via a browser) would the user need to log off for the X server / Xfs to see it? -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Help with fixed fonts
Keith Packard wrote: ... [text about the benefits of client side font handling] We singing in the same choir. To some extent; this just means that clients are in control of their fate. Place fonts in the X server and you can add features to *all* applications in one place. Yes, but two years later after people have upgraded their X server (when they upgraded their OS). There is no mechanism to automatically upgrade the X server and I think it silly and presumptive to ask users to disturb their environment to add a feature to an app (that is assuming they even know that this is a possibility). I certainly would balk if mozilla told me I had to upgrade my X server to get a feature and I'm a mozilla developer. -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]RE: Reworking Xft interfaces
Keith Packard wrote: Around 9 o'clock on Nov 20, Brian Stell wrote: Here is a possible set of choices/fallbacks given a desired font name and desired font encoding-registry or language group (1). 1) Name and encoding-registry / TT language group Best choice. Have you found the TT language group information to be useful in this environment? I fear that far too many fonts will have misleading information in this field. I suspect other operating systems ignore this field, which would cause it to be less than reliable. I look at the ulUnicodeRange fields, which list the supported codepages, to get a language hint. http://www.microsoft.com/typography/otspec/os2.htm While this looks to be useful I do not have enough in-field use to speak authoritatively either way. 2) Name, encoding-* (applies to X fonts only) Regroup fonts that were split apart from a larger font. Good thing I don't have to worry about this; I'm not interested in fonts artificially split apart for the convenience of the core protocol. I thought Xft supported core X fonts. It appears that my plans for Xft have been anticipated by the Mozilla team. That's good to hear, I like to use methods already tried in other environments instead of attempting to invent new ones. I will be great to get this into a common library. It is a big messy piece of code that all X apps could benefit from. While this may be true for X fonts in non-Unicode encodings,, I've found the list of glyphs available in TrueType fonts to vary greatly and randomly; there isn't any apparent rhyme or reason to what's provided. I think this will make the selecting job harder. I suspect that we will find a funny kind of self fullfilling prophecy here. Font vendors supply the characters/glyphs they thing people will use. People build web pages using these fonts and find that some characters do-not-work or look-bad (because they are not in the font) and thus avoid those characters. -- Brian Stell mailto:[EMAIL PROTECTED] ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]RE: Reworking Xft interfaces
Keith Packard wrote: Around 22 o'clock on Nov 19, Brian Stell wrote: Not all apps know which characters will be needed when until after the font is needed/loaded. That's why I'm trying to create an API that can represent fonts in a glyph-set independent fashion. Do you have any comments on whether my list-all-the-fonts method seems reasonable? Please understand that this list is strictly conceptual; the implementation could cull fonts in various ways to avoid overwhelming the application with useless fonts. That brings up another difficult issue though; I'd like to provide the application with as much information as possible in case it wants to try and present certain text in the same font. The obvious mechanism for culling fonts from this list would be to eliminate fonts which don't increase the Unicode coverage over the union of fonts matching the pattern more closely; this fails to present fonts which might contain just the set of glyphs needed for a particular document (or paragraph, or whatever unit the upper level software decides is important). Fonts are always a difficult business since every system has different fonts and users want the code to use the best fonts on *their* system. As such, I took a strategy years ago to have a multilayered fallback. If the 1st choice is not available, try the 2nd choice. If the 2nd choice is not available, try the 3rd choice and so on. The best choices are placed at the beginning and by having a series of fallbacks the code can degrade as gracefully as possible. Here is a possible set of choices/fallbacks given a desired font name and desired font encoding-registry or language group (1). 1) Name and encoding-registry / TT language group Best choice. 2) Name, encoding-* (applies to X fonts only) Regroup fonts that were split apart from a larger font. 3) Name, *-* / any language group This assumes that fonts of the same name (say Helvetica) but different language groups will more nearly match than differently named fonts (say Courier). This is not completely true for some CJK fonts. 4) *, encoding-registry / language group Try to get a font from the same language group; eg: Japanese fonts are more likely to look similar to each other than to a Chinese font. 5) *, encoding-* (X fonts only) A little bit looser specification. 6) *, * This is the pick anything stage. Honor the font path order but otherwise just pick any font that has the character. At each step of the way pick the font with the characteristics that most nearly match the desired characteristics; eg: bold/italic/thin/etc. This is approximately the way that the list of fonts is generated in Mozilla. The list is always the same regardless of the order characters are found in a document. To avoid unneeded searching the search only proceeds down the list far enough to satisfy the characters that have been seen *so far*. Most font-lists never get to the pick anything stage and typically the font-lists contain many fonts that have been selected but not actually loaded. X fonts have an encoding-registry with a well known set of characters (ignoring iso10646 fonts for the moment). This tends to mean once a font of a given registry-encoding is added to the list there is no point in adding other fonts with the same encoding-registry. While Mozilla avoids these duplicated fonts at any particular step of the search I suspect the font-list could have fonts with the same encoding-registry added at different steps. The obvious mechanism for culling fonts from this list would be to eliminate fonts which don't increase the Unicode coverage over the union of An interesting idea that would seem most beneficial for case where the code was at the pick anything stage. Hopefully, however, this will be the very rare exception not the norm. Notes: 1: For TrueType language groups see http://www.microsoft.com/typography/otspec/os2.htm#ur 2: asterisk '*' means wildcard or any Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]RE: Reworking Xft interfaces
yao zhang wrote: ... The 'character set' idea will be very help. Internally, the unicode char map is really a bitset. An ascii formatted version of the bitset can be specified in a font pattern. But a group of pre-defined bitsets should also be specified by the character set part of an existing standard (not the encodinging part of the standard): Latin-1, GB2312, BIG5, CJK Unified Ideographs, etc. Those string constant are just aliases to the underline unicode char maps. It is very useful since most existing fonts are design for one particular character set of a standard anyway. This may have been (generally) true of X fonts but TrueType fonts are being designed for Unicode and do not support all of Unicode. The application is expected to compute the set of glyphs needed to represent the data. Not all apps know which characters will be needed when until after the font is needed/loaded. Consider: browser display a pages as they arrive word processors display pages as the user types -- Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
