[OpenFontLibrary] Open Font Library Podcast: Dev Talk #1

[Ed Trager]

Hi, everyone,

On Wed, Jun 3, 2009 at 2:08 PM, Behdad Esfahbod <behdad at behdad.org> wrote:
> On 06/03/2009 02:02 PM, Ben Weiner wrote:
>>
>> Hi,
>>
>> Behdad Esfahbod wrote:
>>>
>>> Ok, listening. It still slightly worries me that all the new code
>>> being written is duplicating lots of code that is already out there...
>>
>> OK, well, please give us some more hints about which functionality we
>> shouldn't be duplicating... ;-)
>
> "pcp?"  The preview-generating tool.  I want to see any missing features
> added to pango-view instead.

pcfp is currently a very simple tool for generating the previews.
Currently, pcfp just generates a single line of typeset text as a
preview.  I mentioned in the recorded development conversation with
Ben Weiner and Dave Crossland that I may want in the future to add
options to pcfp to make it capable of producing a "waterfall"
specimen, or a "drop caps" specimen. I'm sure people on this list can
think of a gazillion possibly useful options beyond just these few.  I
will certainly take a look at pango-view and see what it does and what
options are there, and see where it is best to make additions or
modifications in the future.

Note that while "pcfp" is currently used for generating the previews,
most of my time was actually spent on creating the "FontPlayground"
and "Key Curry" Javascript classes that drive the interactive web
interface.  pcfp was something I needed on the server side, so I wrote
pcfp (and it didn't take much time to do that): I'm sure that
pango-view or similar tools can be swapped in place of pcfp if it is
generally agreed that a more versatile tool with a better array of
options is needed in the future.

> Fontaine also overlaps with fontconfig and
> pango in huge parts.

I'm not as convinced that fontaine overlaps so extensively with
fontconfig.  The way orthographies are grouped in fontaine is quite
different than in fontconfig.

The treatment of Japanese illustrates the difference well:  Fontaine
breaks up "Japanese" into a set of categories that are meaningful to
Japanese people: Jinmeiyo, Joyo, and Kokuji represent different
classes of Kanji, and then there is of course a separate group for
kana (hiragana, katakana).  For a typographer working to produce a
Japanese font, being able to generate a report where things are
organized into these groupings makes sense.  Fontconfig on the other
hand --correct me if I am wrong-- has a single grouping for "Japanese"
orthography, which lumps all the Kanji and kana.  This is just one
example.  There are differences in the approach fontaine takes for
other orthographies as well.

Overall, the general distinction is that fontaine uses
orthographic-centric groupings that are intended to be most relevant
to fonts and digital type design.  As I understand it, fontconfig uses
language-centric groupings.

There is of course nothing wrong with fontconfig's approach -- or, for
that matter, with Fontaine's approach.  They simply serve different
purposes.

> I replied to that in another thread a couple montsh
> back.  Maybe if I find some time I hack something...
>
>>> Also, Ed talks about fontconfig being a mystery. If someone doesn't
>>> understand some part of it, all they need to do is ask. I'll explain
>>> until they understand :).
>
>>
>>
>> What happens if you get kidnapped or lose your internet connection?
>
> See, I write the code.  Ed already contacted me and I told him how I think
> this should be done.  He didn't CC the list (he's not on the list?)

I'm on the list -- I wasn't paying attention when I emailed Behdad the
other day, so I forgot to reply all or CC the list ...

> , so I
> attach the relevant parts at the end of this message.
>
> Anyway, point being that, now he knows how things work, and he's much better
> than me in writing.  So he can write good docs!  Same applies to everyone
> else: ask, I'll make sure I answer, you can then write it in a legible form
> :).

Heh, heh, you are assuming that I like writing documentation ...

Best - Ed

>
> behdad
>
>
>>
>> QUESTION:
>>
>> So, if I add a font file to a subdirectory of a directory that
>> fontconfig knows about (via the fontconfig conf file), does fontconfig
>> rescan that subdirectory and re-cache immediately?
>
> Any new process notices that immediately and updates the cache (make sure it
> has permission to do so).  Or you can call FcInitReinitialize().  However, I
> strongly recommend that you keep all the font dirs out of the default
> fontconfig config, and add only the directory for the font you are dealing
> with into the config using FcConfigAppFontAddDir().  That should avoid lots
> of possible scalability as well as security issues.  I'd even recommend
> using different cache dirs for each font dir.
>
>> Or, alternatively, is it necessary to call fc-cache manually?
>>
>> SCENARIO:
>>
>> The scenario for uploading new fonts to OFLB is that the fonts will be
>> placed in a subdirectory of the "files/" path.  The fontconfig conf
>> file will know about the parent directory called "files/".  A new
>> subdirectory under "files/" may be created at any time to contain a
>> new set of one or more newly uploaded TTF or OTF font files.  The
>> program that generates a bitmap PNG preview of the font is called
>> "pcfp" and it uses Pango-Cairo.  The exact font family and style
>> names, e.g., "Gentium Italic" will be passed to the pcfp.  Since we
>> only want to use glyphs from the specified font, the fontconfig conf
>> file is setup to use SIL's "hex box" fallback font for all
>> substitutions.  That way, if some glyph is missing from the specified
>> font, a hex box will be shown  -- this way, we know right away if
>> something (such as an extended Latin character) is missing from the
>> font.
>
> If you keep the default fontconfig config empty of fonts and just add the
> dir for new fonts, pango will *only* see those fonts and will draw hexboxes
> for everything else.
>
> Alternatively you can turn font fallback off in pango using the
> PangoAttrFallback attribute.
>
>
>> I assume that Fontconfig will indeed rescan and recache immediately.
>> But at this juncture, that is just an assumption on my part.  So that
>> is where the "mystery" is for me ... and it is really only a mystery
>> because I haven't tested it myself yet.
>
> Well, test it then :).  Since many many fonts in the upload area may have
> the same family name, style, etc, it's essential to implement the scheme I
> suggest above or a variant thereof.
>