Technical: reverse-mapped 'μΔfifl' (detected by warning in FontForge)

Reported by Alan Bell on 2010-09-07
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Font Family
Medium
Unassigned

Bug Description

The following warnings are shown when opening the individual font .ttf files in FontForge (see screenshot):

  The following table(s) in the font have been ignored by FontForge
    Ignoring 'LTSH' linear threshold table
    Ignoring 'VDMX' vertical device metrics table
    Ignoring 'hdmx' horizontal device metrics table
  This font contains both a 'kern' table and a 'GPOS' table.
    The 'kern' table will only be read if there is no 'kern' feature in 'GPOS'.

  The glyph named mu is mapped to U+00B5.
    But its name indicates it should be mapped to U+03BC.
  The glyph named Delta is mapped to U+2206.
    But its name indicates it should be mapped to U+0394.
  The glyph named fi is mapped to U+F001.
    But its name indicates it should be mapped to U+FB01.
  The glyph named fl is mapped to U+F002.
    But its name indicates it should be mapped to U+FB02.

Alan Bell (alanbell) wrote :
Paul Sladen (sladen) on 2010-09-08
description: updated
Changed in ubuntu-font-family:
status: New → Triaged
importance: Undecided → Medium
Paul Sladen (sladen) wrote :

Breaking those down:

  (1)-(3) are about tables that Fontforge does not yet handle.
  (4) is I presumed duplicated for compatibility; we should file this separately and look into it
  (5)-(8) are coherency sanity checks, and we should probably investigate those

Paul Sladen (sladen) wrote :

Last four errors:

  (5) 'µ' vs. 'μ'; Unicode allows a distinction between MICRO SIGN and GREEK SMALL LETTER MU
  (6) '∆' vs. 'Δ': Unicode allows a distinction between INCREMENT and GREEK CAPITAL LETTER DELTA
  (7) '' vs. 'fi': Private use area and LATIN SMALL LIGATURE FI
  (8) 'fl' vs. 'fl': Private use area and LATIN SMALL LIGATURE FL

It would of course be great to have an open font that opened in an open font editor without opening errors.

The first pair possibly want swapping, or aliasing in a slightly different manner (Malcolm might be the person to clarify this).
The second pair have copies in the Private Use Area, probably left over for testing purposes and should clear with their removal if they're not ultimately needed.

summary: - warnings when opened in fontforge
+ Technical: 'μΔfifl' aliasing highlighted as warning in FontForge
tags: added: ttf-greek ttf-ligature ttf-private-use-area ttf-technical
Paul Sladen (sladen) on 2010-09-30
Changed in ubuntu-font-family:
milestone: none → 0.69
Paul Sladen (sladen) on 2010-09-30
summary: - Technical: 'μΔfifl' aliasing highlighted as warning in FontForge
+ Technical: reverse-mapped 'μΔfifl' (detected by warning in FontForge)
Changed in ubuntu-font-family:
status: Triaged → Confirmed
importance: Medium → Low
Paul Sladen (sladen) on 2010-09-30
Changed in ubuntu-font-family:
importance: Low → Medium

(a) FontForge warning: The glyph named mu is mapped to U+00B5.
    But its name indicates it should be mapped to U+03BC.
  The glyph named Delta is mapped to U+2206.
    But its name indicates it should be mapped to U+0394."

the 'mu' is mapped to x00B5 since this was the historical WinANSI and MacUS character code point and PostScript name. The Greek x03BC is giving the name 'uni03BC' in accordance with Adobe's recommendations for glyph names.

(b) FontForge warning: The glyph named fi is mapped to U+F001.
    But its name indicates it should be mapped to U+FB01.
  The glyph named fl is mapped to U+F002.
    But its name indicates it should be mapped to U+FB02."

Glyph 'fl and fi' were originally assigned (by Apple;TrueType spec 1.0) to the Unicode 'private use area' xF001 and xF002 which became an industry standard characters and Unicode values.

The Unicode Consortium at the time did not consider the fi or fl to be valid Unicode characters because they are ligatures and made from 2 existing Unicode characters.

Later Unicode changed its mind and assigned two new values of xFB01, xFB02 for the 'fi' and 'fl' ligatures. For backward compatibility reasons the 'fi' and 'fl' should exist in all fonts and retain their values of xF001 and xF002 and two new glyphs are added and name 'f_i' and 'f_l' also to follow the Adobe recommendations for naming ligatures.

Alan Bell (alanbell) wrote :

so should this be filed as a bug in fontforge, or is it still valid to warn about such things?

Paul Sladen (sladen) on 2010-09-30
Changed in ubuntu-font-family:
status: Confirmed → Triaged
milestone: 0.69 → 1.00
Paul Sladen (sladen) wrote :

Vincent: thank you for the comprehensive write-up. I've notched it back from being milestoned, as it's not as clear-cut.

If we were to address the question of whether we are /likely/ to encounter a document relying on the U+F001/U+F002 encodings for fi and fi then this document would need to pre-date the Unicode assignment (note: the Ubuntu distribution does contain documentation at least this old...); however the is a standardised Unicode assignment /now/ and we should be using that and ensuring that others do too.

We have already seen (bug #615565, Romanian comma/cedilla accents) that Adobe's glyph list is not infallible. Within Linux/Ubuntu there is a tendancy towards tackling root-causes of issues, rather than carrying unused baggage as workarounds into the future.

The /correct/ method of fixing the lack of codepoint deficiency was to get Unicode to assign proper codepoints for the fi/fl ligatures, and this was accomplished in Unicode Version 1.1.0, *in 1993*. I think my personal take would be that where Unicode mappings exist, they trump /everything/ else, as we should follow the international standard (which are there for exactly that purpose).

If we did indeed encounter a document that was using codepoints U+F001 or U+F002, how would we know that the document was expecting fi/fl, rather than a specialised logo? The answer is that we wouldn't... in which case there is no reason to support an ambiguity where one should not exist.

We have the possibility here for a modern font, laid out technically beautifully: at the meta-data level, as well as the visual level. Without Unicode we would be in a big mess; Unicode is our friend and our guide here.

It's very unlikely that you'll encounter documents which contain
U+F001/U+F002. The reason for codepoints being granted for the ligatures
was to allow a one-to-one mapping from legacy encodings which included
the characters, such as Windows CP-1252. They are just presentational
forms so they won't have been widely used in real Unicode documents at
the time

Dave

Paul Sladen (sladen) wrote :

> It's very unlikely that you'll encounter documents which contain U+F001/U+F002.

I agree. I think this supports the idea that we shouldn't be shippings these legacy mappings; they're not being used, they're wrong/broken anyway and carrying them means that we're carrying baggage that isn't of useful relevance (15 years ago, today, or tomorrow).

Hopefully we can sort the canonical (small 'c') mappings out later, but in the meantime could we remove the aliasing of fi and fl into the PUA. I can only see it causing us problems down the line through sustaining bad habits.

There is a difference between 'legacy' and 'wrong'. In many cases, once
a precedence is out it cannot be revoked on fear of non-conformity and
omissions.

Imagine the user who receives an (old) pre-proofed document. Runs the
document through an Ubuntu based app to go to print. Not until they have
had run-off 100,000 do they notice that every 'fi' or 'fl' has turned
into a notdef rectangle.

Who will they turn to for compensation...the app developer, Canonical,
DaltonMaag?

http://www.microsoft.com/typography/otspec150/WGL4E.HTM

What problems do you anticipate down the line from including these
legacy mappings?

Malcolm Wooden

On 30/09/2010 16:42, Paul Sladen wrote:
>> It's very unlikely that you'll encounter documents which contain
> U+F001/U+F002.
>
> I agree. I think this supports the idea that we shouldn't be shippings
> these legacy mappings; they're not being used, they're wrong/broken
> anyway and carrying them means that we're carrying baggage that isn't of
> useful relevance (15 years ago, today, or tomorrow).
>
> Hopefully we can sort the canonical (small 'c') mappings out later, but
> in the meantime could we remove the aliasing of fi and fl into the PUA.
> I can only see it causing us problems down the line through sustaining
> bad habits.
>

--
Malcolm Wooden, Font Production, Dalton Maag Ltd
Unit 107, 245A Coldharbour Lane, London, SW9 8RR, UK

A new contemporary serif font family: http://www.daltonmaag.com/cordale

Registered office: Mutfords, Hare Street, Buntingford, SG9 0ED, UK
Registered in England and Wales: 3103619

Alan Bell (alanbell) wrote :

I feel a user receiving a document that is pre-1993, pre-proofed and also set in the Ubuntu typeface would be hard to find :) That said, I take the point about the legacy mappings and I don't think the current situation is particularly harmful or an appreciable overhead. What I do think is an issue is that the Ubuntu font throws up warnings when opened with the font editor that is in Ubuntu. I think the resolution to this is either to modify the font such that the warnings are not triggered (remove the redundant glyphs) or we decide that the font is right to be compatible with what are now technically broken documents, and we file a bug against fontforge to get the warnings refined such that they don't trigger on this situation we deem to be correct.

Mark Shuttleworth (sabdfl) wrote :

It seems those warnings would be more appropriate in a "lint" function,
not on opening the font.

Mark

Khaled Hosny (khaledhosny) wrote :

For the record, here is a discussion about VDMX and hdmx tables in FontForge:

  https://sourceforge.net/mailarchive/forum.php?thread_name=20080408.081036.179722610.wl%40gnu.org& forum_name=fontforge-devel

If those are needed for Ubuntu font then someone have to add that support...

Khaled Hosny (khaledhosny) wrote :

> It seems those warnings would be more appropriate in a "lint" function,
> not on opening the font.

Since FontForge is a font editor rather than a mere viewer, I find it very valuable to make such warning very visible since it should be taken into consideration (wrong glyph names affects copying text in PDF readers, for example).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers