Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1410983 - texlive-ebgaramond contains historical flags (i.e., flags obsolete for centuries) as Unicode flag emoji
Summary: texlive-ebgaramond contains historical flags (i.e., flags obsolete for centur...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: texlive
Version: 25
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-07 05:19 UTC by Kevin Kofler
Modified: 2017-02-26 01:38 UTC (History)
2 users (show)

Fixed In Version: texlive-2016-32.20160520.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-26 01:38:08 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Kevin Kofler 2017-01-07 05:19:27 UTC
Description of problem:
What I am seeing is really a conjunction of unfortunate design decisions, which really mess things up:
* The EB Garamond upstream font decided to map some historical flags (i.e., flags obsolete for centuries) to the Unicode flag emoji code points:
https://bitbucket.org/georgd/eb-garamond/commits/all?search=flag
* TeXLive includes that font as part of the texlive-ebgaramond package. That package is required by (at least) texlive-collection-latexextra, texlive-collection-fontsextra and texlive-moderncv.
* Somehow (I don't know whether this is by design or something messed up in my configuration), the TeXLive fonts end up in my system-wide font search path. (Is that a deliberate feature or a bug?)
* Since most other fonts do not include the relevant code points, Fontconfig decides to pick up the EB Garamond flags through the fallback font mechanism for almost all fonts on the system, including DejaVu Sans, Liberation Sans, etc.

As a result, I end up with web pages such as:
http://emojipedia.org/flags/
displaying really weird "Chinese", "French", "Norwegian", and "Spanish" flags. (Only the UK one makes any sense in today's world.)

Version-Release number of selected component (if applicable):
texlive-ebgaramond-svn35662.0.16-24.fc24.1.noarch

How reproducible:
Always? (It needs to be confirmed whether it is normal that TeXLive fonts end up in the system-wide search path or not, and if not, what did that.)

Steps to Reproduce:
1. Install texlive-ebgaramond.
2. Browse to http://emojipedia.org/flags/ with a browser other than Firefox. (Try, e.g., QupZilla.) The "other than Firefox" restriction is because Firefox uses its own bundled Emoji One font to display emoji, not fontconfig fonts.

I also have the gdouros-symbola-fonts package installed, which sorta covers those code-points (it displays the flags just as their country code, i.e., the characters composing them, because it does not implement the ligatures), but fontconfig decides to not use that one. I have not tested yet whether installing other Emoji fonts such as the google-noto-emoji-fonts would help.

Actual results:
Unrecognizable obsolete (centuries-old) flags.

Expected results:
Modern-day flags, or the country code, or a replacement character (the box or the Unicode boxed question mark). Anything is better than a wrong/outdated flag.

Comment 1 Kevin Kofler 2017-01-08 03:08:31 UTC
The same happens on Fedora 25:
texlive-ebgaramond-svn35662.0.16-22.fc25.1.noarch

Comment 2 Tom "spot" Callaway 2017-01-16 21:47:54 UTC
Users wanted TeXLive fonts to end in the system-wide search path, so that is intentional. This situation is obviously an unintended consequence. :/

I've removed ebgaramond from the system path in -31, which is building now for F25/rawhide.

Comment 3 Fedora Update System 2017-01-17 14:49:52 UTC
texlive-2016-24.20160520.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-edf549ecaf

Comment 4 Fedora Update System 2017-01-19 09:07:16 UTC
texlive-2016-24.20160520.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-edf549ecaf

Comment 5 Fedora Update System 2017-02-22 03:21:20 UTC
texlive-2016-32.20160520.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-b10c075994

Comment 6 Fedora Update System 2017-02-22 21:09:16 UTC
texlive-2016-32.20160520.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-b10c075994

Comment 7 Fedora Update System 2017-02-26 01:38:08 UTC
texlive-2016-32.20160520.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.