Re: [Pkg-fonts-devel] Fwd: Draining the font swamp
On Mon, May 28, 2007 at 06:12:12PM +0100, Matt Zimmerman wrote: On Thu, May 24, 2007 at 11:28:09AM +0800, Arne Götje (高盛華) wrote: - Which applications ask for which font specifications, and where that's configured (sometimes in the application itself, as in Firefox) yes, firefox is a horrible application in this regard. Are there any ways to change that behavior? I don't know, though perhaps Alexander does (CCed). In general, firefox uses fontconfig. However, iirc, some system font setting are not properly applied - like anti-aliasing on a per-font base. Arne, do you have any specific suggestions on what should be improved changed? - Alexander -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
This swamp must be keeping the developers out - scary place! :D /d -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: [Pkg-fonts-devel] Fwd: Draining the font swamp
On Sun, May 20, 2007 at 08:52:48AM +0200, Christian Perrier wrote: (sorry for the crosspost. Please reduce if inappropriate) Thanks for cross-posting; this issue applies to Debian as well, and we would appreciate input from the Debian community. I wasn't aware of pkg-fonts-devel. -- - mdz -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Draining the font swamp (Matt Zimmerman)
What I'm concerned with in this thread is the experience of an average user, who cares very little about fonts, just wants their applications to work, and be able to display readable text in their language. We want to have the simplest, cleanest infrastructure to provide this. This is the challenge for any complex application. Provide simple defaults for ordinary or casual usage, but allow access to the complexity if wanted. Too few developers think about this. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
Op zaterdag 19-05-2007 om 12:34 uur [tijdzone +0100], schreef Matt Zimmerman: There has been some confusion and dissatisfaction over the treatment of fonts in Ubuntu for a some time now, and no common understanding of how to improve the situation. I spent a little time thinking about this today, and would like to present some questions whose answers I hope will help us to make some progress. My problem with fonts in Ubuntu is the same problem/dilemma that I had with fonts on Windows in the past: * I want to be able to have a lot of fonts installed on my system, so that things look like they are intended to look when viewing them. * I don't want all of those fonts to be listed in the default font dialogs and font selection widgets. And when I'm doing graphic/design work: * I want to have hundreds or thousands of fonts available and those that I use in a certain project (which can involve lots of different applications) easily accessible. One possible solution to the issues above would be to add a system to fontconfig (or on top of it) that allows for the concept of what I call font groups. Font groups are a group of related fonts (hence the name ;) ), and can maybe also contain other font groups. Allowing font groups to be members of other font groups would make them more flexible and more powerful, while not necessarily making the user interface more complicated. An example might be to have both locale-defined and user-selected fonts in the default font group (see below) There would be both handpicked and dynamic font groups, where dynamic means that the contents of that font group are based on a selection rule that bases on the font metadata (e.g. all fonts that contain cyrillic glyphs or all fonts of the DejaVu Sans family). There would also be a default font group which contains the fonts that will be shown in a default font selection dialog or widget. This default group could be defined by the current locale (dynamically based on font metadata and/or a predefined selection for that language). Font selection widgets and dialogs would have to be changed to add a way to select another font group, and maybe also a way to edit font groups (this should be implemented by launching a separate application, to allow distros and operating systems to implement it their way). Also, applications should be able to create their own font groups (e.g. related to a project) and also use such font groups created by other applications. In practice, they would use this to open a font dialog or font selection widget with another font group than the default one. Font packages could also contain font groups definitions to add to the system when installing them. I'm thinking about superfamilies or the name of a font collection. I think ideally the font group technology would be implemented in libfontconfig somehow, and then desktop frameworks applications should add support for it. (Of course that would also require fixing OOo, Firefox, etc.) The biggest problem might be to convince all the projects involved to cooperate on implementing this... :) -- Jan Claeys -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
On Fri, May 25, 2007 at 01:31:08PM +0200, Jan Claeys wrote: Op zaterdag 19-05-2007 om 12:34 uur [tijdzone +0100], schreef Matt Zimmerman: There has been some confusion and dissatisfaction over the treatment of fonts in Ubuntu for a some time now, and no common understanding of how to improve the situation. I spent a little time thinking about this today, and would like to present some questions whose answers I hope will help us to make some progress. My problem with fonts in Ubuntu is the same problem/dilemma that I had with fonts on Windows in the past: * I want to be able to have a lot of fonts installed on my system, so that things look like they are intended to look when viewing them. * I don't want all of those fonts to be listed in the default font dialogs and font selection widgets. And when I'm doing graphic/design work: * I want to have hundreds or thousands of fonts available and those that I use in a certain project (which can involve lots of different applications) easily accessible. One possible solution to the issues above would be to add a system to fontconfig (or on top of it) that allows for the concept of what I call font groups. Sounds like you want a specialized tool like fonty-python, designed for people who do this kind of work. What I'm concerned with in this thread is the experience of an average user, who cares very little about fonts, just wants their applications to work, and be able to display readable text in their language. We want to have the simplest, cleanest infrastructure to provide this. -- - mdz -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
[CC'ed Donn Ingle as I point to his reaction on Mark's blog[1]--Donn, see [2] for my original proposal; I think subscribing is required before mailing to ubuntu-devel-discuss] Op vrijdag 25-05-2007 om 13:40 uur [tijdzone +0100], schreef Matt Zimmerman: Sounds like you want a specialized tool like fonty-python, designed for people who do this kind of work. No! If properly implemented, most people would (almost) never have to do anything that they don't do now. I have been thinking about this for more than 2 years, after seeing the way too long font list (even before I installed the hundreds of fonts that I have). I have used font managers like Fonty-Python and those included in Adobe products before, on Windows and Mac OS Classic and they are usable but not perfect. And the way Fonty-Python works is a hackish workaround, as the author says himself in the comments on Mark's blog[1], but it's the best that can be done using the current infrastructure. It actually has to install and uninstall fonts (by symlinking them in '~/.fonts'), which is not the same as hiding them from the default font dialogs (it breaks when you try to view a document without installing the fonts used in it first). What I'm concerned with in this thread is the experience of an average user, who cares very little about fonts, just wants their applications to work, and be able to display readable text in their language. We want to have the simplest, cleanest infrastructure to provide this. What I describe provides an infrastructure that can be used for making things better for both ordinary users (they would mostly use what I call the 'defaults' font group) *and* for graphics professionals (even a better solution than Apple, Adobe, etc. have now!). It's just like apt/dpkg with its system for software installation, dependencies, etc. sits under gnome-app-install, Synaptic, aptitude, ... The default font manager could be similarly easy as g-a-i, while an advanced GUI for power users could be provided as a package for download. [1] http://www.markshuttleworth.com/archives/119#comment-97178 [2] https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-May/000997.html -- Jan Claeys -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
[CC'ed Donn Ingle as I point to his reaction on Mark's blog[1]--Donn, see [2] for my original proposal; I think subscribing is required before mailing to ubuntu-devel-discuss] Jan, thanks for the CC - I have joined devel-discuss and will follow the thread as it goes. I have yet to read your idea (and this thread), so I won't repeat what I said on Mark's blog in case it's complete bollocks :D /d -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
I received this reply off-list; it was only sent to pkg-fonts-devel. Copying back to ubuntu-* as well, as it's very informative. -- - mdz ---BeginMessage--- pgpFnfiU3AlJz.pgp Description: PGP message ---End Message--- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
On Thu, May 24, 2007 at 02:59:41PM +0100, Matt Zimmerman wrote:
On Mon, May 21, 2007 at 10:59:42PM -0500, Ming Hua wrote:
I believe the general consensus among Chinese users is that bitmap fonts
are preferred for small font size.
Do the xfonts-* fonts fall into these categories?
Yes, they are the stand-alone bitmap fonts I mentioned, sorry for
being unclear.
So to re-iterate, I believe most, if not all, Chinese users prefer
bitmap fonts for small font sizes. This can be achieved in two ways,
stand-alone BDF/PCF fonts, such as the ones in xfonts-* packages, or
embedded bitmap in TrueType fonts, and the only such TT fonts available
in Debian/Ubuntu are ttf-arphic-{uming,ukai}.
I'm not sure what character set they cover.
That's a question I don't have clear answer either. I know xfonts-wqy
covers quite a wide range of CJK characters, and their most recent
release definitely cover GBK (a.k.a. Windows code page 936), which
should satisfy simplified Chinese (zh_CN) users' need. It should also
cover Big5 (a.k.a. Windows code page 950) for the need of traditional
Chinese users in Taiwan (zh_TW). I think it doesn't cover Big5-HKSCS
yet, which is needed by traditional Chinese users in Hong Kong (zh_HK).
Note Debian/Ubuntu currently haven't packaged the most recent release
though.
The two TrueType fonts, ttf-arphic-{uming,ukai}, should be using the
same set of embedded bitmaps. This set of bitmaps are not the same as
the xfonts-wqy font, but some subset of them may share the same origin.
As the upstream author, Arne, is also participating this discussion, he
should know more details if it's an important piece of information.
Both xfonts-wqy and ttf-arphic-* also have some coverage for Japanese
and Korean characters. But I have no idea about how complete the
coverage is or what quality the glyphs are. I also haven't heard much
about Japanese and Korean users using these fonts, they have their own
preferred TrueType fonts, and maybe bitmap fonts as well.
P.S.: I'm subscribed to all these three lists, so cc: is not necessary. :-)
Ming
2007.05.24
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
Matt Zimmerman wrote: - Xfont, which provides font services (including selection and rendering) through the X server. This is basically obsolete in favour of client-side fonts. Why is this? Client side fonts are bad for several reasons: 1) You end up with the mess you point out, where you have several different client side font systems. 2) That leads to code that is harder to maintain and configure and troubleshoot. 3) Performance suffers. The X server is in the best position to render fonts using any hardware acceleration provided by the video card, and allows for those fonts to be shared by all applications, reducing duplication and waste. Also for remote X sessions, you want the fonts rendered on the server so much less data needs exchanged between the client and server. Other than the fact that the client side implementations have advanced beyond the X server ones in recent times, is there any advantage to client side font rendering over server side? If not, then we should push to bring the client side advancements back into the server where font rendering belongs. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
On Mon, May 21, 2007 at 10:52:46AM -0400, Phillip Susi wrote: 3) Performance suffers. The X server is in the best position to render fonts using any hardware acceleration provided by the video card, and allows for those fonts to be shared by all applications, reducing duplication and waste. Also for remote X sessions, you want the fonts rendered on the server so much less data needs exchanged between the client and server. Measurements have shown that over pretty much any sort of common network, latency is more of a problem than bandwidth. Server-side fonts require multiple round-trips between the server and the client for rendering, whereas client-side fonts only require the initial display. Performance-wise, we have the XRender extension for precisely this sort of situation. Other than the fact that the client side implementations have advanced beyond the X server ones in recent times, is there any advantage to client side font rendering over server side? If not, then we should push to bring the client side advancements back into the server where font rendering belongs. Font choice and layout is hard, and doesn't become any easier just because you've moved that code to a binary that runs as root. Nobody is going to argue in favour of putting a layout engine like Pango in the X server, and most of the rest of the stack is similarly well outside the scope of the X server. The client-side font revolution happened 5 years ago, and we've ended up with massively improved font support as a result. -- Matthew Garrett | [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
On Mon, 2007-05-21 at 15:09 -0400, Phillip Susi wrote: How does server side fonts require more round trips? It should amount to a single message that specifies what font to use, what text to render, and where. Only after a detailed exchange to determine the character-set coverage of the font in question, and to perhaps request additional fonts to cover those characters that are missing; then to calculate the metrics of the font to see whether it will fit into the assigned area, and perform word-wrapping (each requiring more metric checking round-trips). Lots of back-and-forth. With client side fonts, the client has to have the fonts in the first place, then has to render them The server has to both of these too, so it doesn't matter which side you put the having or the rendering. then send them as a bitmap to the server. If you want to do things like anti aliasing, then the client has to read a bitmap from the server, then render the font into it, then send the resulting bitmap back to the server. Not true. This is what the Xrender extension is all about. The client just needs to send the rendered font, which may in fact be a series of X protocol (or GL, etc.) drawing commands. At the worst, it'd be a transparent pixmap. Just one send, regardless. Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
On Mon, May 21, 2007 at 01:13:56AM +0100, Nicolas Spalinger wrote: - Whether we still need all these horrible bitmap fonts You mean the fonts available in the x-fonts* packages? I think the names are xfonts-*. Last time I checked, X server won't start without the fixed bitmap font from xfonts-base. I would suggest a poll on usage and possible demotion to universe or specific langpacks. Might be different for CJK fonts. I believe the general consensus among Chinese users is that bitmap fonts are preferred for small font size. There is a technique called embedded bitmap that can put bitmap fonts of different size into a TrueType font, and libfreetype handles this correctly. There are currently one set of fonts (with two typefaces) in Debian/Ubuntu that has embedded bitmaps. A sad thing, however, is that although there is a group actively working on a set of Chinese bitmap fonts and has improved the quality quite a bit, their work can't be embedded into the existent TrueType font due to licensing restrictions. So I am afraid in the short term stand-alone bitmap fonts are still necessary for Chinese users who are picky about font rendering. Ming 2007.05.21 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
On Sat, 2007-05-19 at 12:34 +0100, Matt Zimmerman wrote: - Exactly which pieces are used by GTK, Qt, XUL, etc. and how applications using those APIs ask for a font specification You forgot the following, which is what GTK+ uses ... - Pango, a text layout and rendering engine with an emphasis on Internationalisation. Given a string of UTF-8 text, and a preference of fonts, it selects appropriate fonts to cover the characters being written and renders them to the screen. Uses combination of fontconfig, freetype, Xft and Cairo (some languages have native non-font renderers) Also another question: - Why are there so many differences of opinion about how much hinting fonts require, which method of hinting to use, and which of the results looks better Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Draining the font swamp
There has been some confusion and dissatisfaction over the treatment of fonts in Ubuntu for a some time now, and no common understanding of how to improve the situation. I spent a little time thinking about this today, and would like to present some questions whose answers I hope will help us to make some progress. Please correct me where I've misunderstood, as I've only done some cursory research here. Hi Matt and everyone, Thanks for raising these key issues. Here are some initial thoughts and pointers from my perspective. We seem to have: - Loads of fonts, in various formats (TrueType, Type-1/PostScript, PCF bitmap, Metafont, others?) supporting various character sets, of varying quality - fontconfig, a font management framework which seems to be used by of the applications we care about in one way or another. It catalogues the fonts on the system and is independent of any window system, font rasterizer, etc. It just knows about fonts and provides an API to find a font based on complicated matching criteria. - DeFoMa, which attempts to allow packages to register fonts with whatever font management frameworks might exist. - TeX. Enough said. It's worth pointing out that with the new texlive2007 in Debian unstable, it's also possible to access TrueType/OpenType fonts from TeX (including smart fonts) via extensions like Xetex: http://packages.debian.org/unstable/tex/texlive-xetex (hats off to the Debian Tex task force!) - freetype, a font rasterization engine which also has some font management capabilities, also used by most applications we care about. Knows how to take fonts and strings and create bitmaps. - Xfont, which provides font services (including selection and rendering) through the X server. This is basically obsolete in favour of client-side fonts. - Xft, a font API for X applications which uses freetype and supports Xrender or plain X drawing to put text on a display. I don't know: - Exactly which pieces are used by GTK, Qt, XUL, etc. and how applications using those APIs ask for a font specification - Which applications ask for which font specifications, and where that's configured (sometimes in the application itself, as in Firefox) There's unification happening via the TextLayout summits bringing together the key font experts in the community: http://www.freedesktop.org/wiki/TextLayout http://live.gnome.org/Boston2006/TextLayout Some blog entries on these meetings: http://labs.trolltech.com/blogs/2007/03/30/working-towards-a-unified-text-layout-engine-for-the-free-desktop-software-stack/ http://rants.scribus.net/2006/10/31/boston-text-layout-summit/ http://mces.blogspot.com/2007/04/metrics-hinting-and-kerning-do-mix.html The next one will be hosted by Akademy 2007 and there will be a report during GUADEC 2007: http://www.guadec.org/node/659 - Which fonts are any good, and for which languages (no easy answer here) Yes, we need an ongoing review and it's no easy task. Some initial work has been started here: http://www.freedesktop.org/wiki/Software/Fonts http://wiki.debian.org/DebianInstaller/GUIFonts http://unifont.org/fontguide/ And there are various ITPs underway for these fonts. I really think the current selection of fonts in a default install needs some serious fixing. Certain packages need to be split, renamed, others need to be moved back to universe as they are more decorative. The way they tie in with langpacks probably also needs review. - Which criteria are important for selecting which font to use in which context (language, character set, ...) I'd say license freeness, unicode coverage, glyph quality, availability of smarts. We probably need a large-scale poll among translators, LocoTeams and users. Although at this stage - but I hope everything is getting in place for a change - for some locales a less than beautiful and feature-rich font is always better than nothing. This is why engaging (funding?) more artists and script experts to design fonts for Debian/Ubuntu is important. The more fonts are available the better the various font-related elements in the free desktop stack can get tested. At the LGM (Libre Graphics Meeting in Montréal) at the beginning of the month there was discussion about setting up a common font QA website between projects like scribus, OOo, OFLB, fontconfig and fontforge. A central place to report troubles with fonts. - Whether fontconfig requires adjustments in order to respect those criteria One key aspect is having a saner font menu by default along with the ability to do more granular font management based on the font metadata. Some of the thinking on this is available on https://wiki.ubuntu.com/FontManagement This fontconfig bug on glyph blacklisting is probably relevant to the language contexts: https://bugs.freedesktop.org/show_bug.cgi?id=7528 Also the fontconfig snippets should go upstream to reduce the deltas with other
Draining the font swamp
There has been some confusion and dissatisfaction over the treatment of fonts in Ubuntu for a some time now, and no common understanding of how to improve the situation. I spent a little time thinking about this today, and would like to present some questions whose answers I hope will help us to make some progress. Please correct me where I've misunderstood, as I've only done some cursory research here. We seem to have: - Loads of fonts, in various formats (TrueType, Type-1/PostScript, PCF bitmap, Metafont, others?) supporting various character sets, of varying quality - fontconfig, a font management framework which seems to be used by of the applications we care about in one way or another. It catalogues the fonts on the system and is independent of any window system, font rasterizer, etc. It just knows about fonts and provides an API to find a font based on complicated matching criteria. - DeFoMa, which attempts to allow packages to register fonts with whatever font management frameworks might exist. - TeX. Enough said. - freetype, a font rasterization engine which also has some font management capabilities, also used by most applications we care about. Knows how to take fonts and strings and create bitmaps. - Xfont, which provides font services (including selection and rendering) through the X server. This is basically obsolete in favour of client-side fonts. - Xft, a font API for X applications which uses freetype and supports Xrender or plain X drawing to put text on a display. I don't know: - Exactly which pieces are used by GTK, Qt, XUL, etc. and how applications using those APIs ask for a font specification - Which applications ask for which font specifications, and where that's configured (sometimes in the application itself, as in Firefox) - Which fonts are any good, and for which languages (no easy answer here) - Which criteria are important for selecting which font to use in which context (language, character set, ...) - Whether fontconfig requires adjustments in order to respect those criteria - Whether we still need all these horrible bitmap fonts - Whether we still need server-side fonts for anything - Whether we need DeFoMa -- - mdz -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
