[Fontconfig] [Behdad] Re: How can I store FC_MATRIX object to cache file?
behdad at behdad.org
Wed Sep 15 10:56:30 PDT 2010
Can you file a bug with reference to these details please?
On 09/03/10 03:50, mpsuzuki at hiroshima-u.ac.jp wrote:
> On Thu, 02 Sep 2010 16:44:35 -0400
> Behdad Esfahbod <behdad at behdad.org> wrote:
>> Can you explain more why the PANOSE values are needed? And, do we need to
>> allow users to query based on them, or just having them in the cache?
> In some popular document formats, like PDF, SVG, ODF and OOXML,
> Panose values are embedded to give the hint for font substitution.
> PDF Reference 6th edition (for PDF version 1.7)
> 5.7.2 Font Descriptors for CIDFonts
> see the description for "Style" entry which
> includes 2 bytes from OS/2.sFamilyClass,
> 10 bytes from OS/2.Panose.
> 20.8.3 The `font-face' element
> there are many elements inherited from CSS2,
> including Panose.
> 14.6.1 CSS2/SVG Font Descriptors
> ODF adopted the elements for the fonts from
> CSS2 and SVG, so even the font is for the text
> (not for embedded scalable graphics), it may
> have Panose value in the svg:panose-1 attribute.
> ISO/IEC 29500-1:2008
> 18.104.22.168 panose1 (Panose-1 Typeface Classification Number)
> OOXML have several font properties (GDI parameters,
> Panose, and supported unicode range). In 17.8.2 Font
> Substitution, there is a list of properties to be
> used in the font substitution, and panose is described
> as the highest priority.
> "PCL 5e Technical Quick Reference Guide"
> "PCL5 Comparison Guide"
> PCL5 selects the font by giving Panose parameters
> sequentially and narrowing down the candidates,
> see PCL 5e Technical Quick Reference Guide p 11-15.
> See table 1-1 "PCL5 Feature Support Matrix" in
> page 1-12 PCL5 Comparison Guide, many PCL5
> implementations support the feature to narrow
> down by Panose parameters.
> Also PCL6 (PCL XL) supports the feature by
> giving a string of PCL5 commands to PCLSelectFont
> In addition, current fontconfig does not have easy element to
> be related with CSS's 5 family classification (serif, sans-
> serif, cursive, fantasy). I think getting FamilyClass & Panose
> values from fontconfig cache may be helpful, because the
> application don't have to open a face, load OS/2 table,
> check FamilyClass/Panose values, close a face.
> The font selection by the matching of familynames & charsets
> leaves a room for an improvement, because severeal documents
> formats (and CSS) have these properties in the documents.
> The query based on these properties is arguable. The algorithm
> to evaluate "best matching" font by Panose is not specified
> in Panose specification paper. If exactly same, it is ok - but if
> different, it is arguable how the similarity should be evaluated.
> Some people want to give the highest priority to serif/sans-serif
> contrast, others want to give it to weight similarity. At present,
> I don't have good idea that everybody think it as acceptable.
> Thus, I think just giving the APIs to provide these properties
> (FamilyClass, Panose, etc) is appropriate starting point. It
> is still convenient for fontconfig client applications because
> they can reduce the costs to open/check/close many font files
> by themselves.
> # In fact, in PCL5, the priority of each bytes in Panose is user
> # controllable.
> Behdad, could I answer to your question? If I'm misunderstanding
> what I was requested, please give me one more chance.
> If putting so many data to fontconfig is bad idea, please let me
>> On 09/02/10 14:24, mpsuzuki at hiroshima-u.ac.jp wrote:
>>> How can I store FC_MATRIX object to cache file?
>>> Now I'm trying to add some properties to fontconfig database,
>>> which are taken from OS/2 and PCLT tables in OpenType: like
>>> sFamilyClass (so-called IBM family classification), Panose etc.
>>> They are useful to guess whether typeface is typographic/scriptic,
>>> serif/sans-serif, proportional/fixed-pitch etc. My original
>>> motivation is an improvement of the font substitution in poppler.
>>> For detail, please find:
>>> Panose in OpenType is a collection of 10 parameters, and
>>> all parameters are expressed by 8bit. 80bit is too large
>>> to pack into double integer, so I have to consider what is
>>> the best way to store such in FcPattern. I think there are
>>> 3 options:
>>> 1) Name all parameters and store separately, aslike,
>>> adding 10 types to FcObjectTypes: FC_OS2_PANOSE_0,
>>> FC_OS2_PANOSE_1, ...
>>> # The name of each byte is different from OpenType spec
>>> # and its reference, so I don't use OpenType spec name
>>> # like FC_OS2_PANOSE_FAMILYTYPE.
>>> 2) ASCII-fy 10 parameters to NULL-terminated string,
>>> and use as a string type property.
>>> 3) Define new data type, a structure including 10 members
>>> and add "FcTypePanose" to FcType.
>>> About 1), it's easy for me to write such patch and for
>>> users to use, but the addition of 10 objects may be too
>>> much, because current variety of the object type is 41.
>>> About 2), it's easy for me to write such patch but tricky
>>> for users to use, because it is requred to decode from
>>> ASCII string to original data.
>>> About 3), it's easiest for users. So I have to consider
>>> about this option.
>>> Checking the source code of fontconfig, FcMatrix data
>>> type looks similar (a structure with fixed length), but
>>> it seems that the data typed FcMatrix cannot be stored
>>> in cache file. I inserted FcMatrix object to FcPattern
>>> and tried to save it in cache file, but it seems that
>>> FcMatrix typed data cannot be saved (fc-cat can read
>>> object type but cannot read value).
>>> The code for FcString, FcCharSet and FcLangSet are
>>> variable length data and have many works. So I want to
>>> know how I can store FcMatrix typed data to cache file.
>>> If option 1) or 2) are acceptable for fontconfig maintainers,
>>> I will do so.
More information about the Fontconfig