Bug 73461 - Gaming of fc-lang check rules
Summary: Gaming of fc-lang check rules
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: orth (show other bugs)
Version: unspecified
Hardware: Other All
: medium enhancement
Assignee: Akira TAGOH
QA Contact: Behdad Esfahbod
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-10 05:20 UTC by Abel Cheung
Modified: 2014-03-18 03:14 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Abel Cheung 2014-01-10 05:20:27 UTC
This report is related to a patch against zh-hk.orth around 2006:

http://lists.freedesktop.org/archives/fontconfig/2006-January/001930.html

It adds an extra Plane 2 code point for determining font supporting Hong Kong characters.

Recently I discovered certain font tries to exploit this check, and only created a *single glyph* in CJK extension B in order to claim it supports zh-hk. I supposed it happened long time ago but nobody noticed. The font concerned is open for download and is actually default font for certain language in certain OS.

So I wonder if determining a policy like this would make sense or not: on orth checks, a certain ballpark percentage of glyphs shall be done in order to claim support, while (1) spreading the glyphs distribution more evenly, and/or (2) create a list of more representative code points reflecting general use of the language when range is large.
Comment 1 Akira TAGOH 2014-01-17 03:25:21 UTC
fixed in git according to your post on the list. thanks!
Comment 2 Abel Cheung 2014-01-18 07:46:46 UTC
Sorry I didn't make my intention very clear before. This report is not intended for any single orth submission; instead, I'm asking if some sort of rules (guidelines if not enforceable) for any future orth file submissions would make sense in general. The previous situation of zh-hk checks begin abused indicate such guidelines would be useful.

Marking this report as enhancement to make my intention more clear.
Comment 3 Akira TAGOH 2014-01-20 02:48:28 UTC
Sure. well, it was sometimes discussed on the list and other orth bugs before. maybe I could quote it as README and put it there.
Comment 4 Abel Cheung 2014-01-21 13:57:36 UTC
Yup, that sounds good enough.
Comment 5 Akira TAGOH 2014-03-07 07:46:40 UTC
just a draft to add:

Requirements for adding new orth file:

* we are following up to the locale name, 2 or 3 letter code
  in ISO 639 and ISO 3166-1 alpha-2 code to determine a
  filename. if it's not yet available, in advance, you
  should get it fixed in glibc or so.

* Please add a reference URL (written in English as far as
  possible) into the orth file that explains the code
  coverage for the certain language. this would helps to
  review if it has enough coverage.

* no need to add all of the codepoints for the certain
  language. good enough if it covers most frequently used
  codepoints in it.

To update existing orth files:

* Please make sure how the changes affects to the existing
  fonts and no regressions except it is expected behavior.

* Please add any reference URL in bugzilla or any
  explanation why it needs to be added/removed and also why
  current orth file doesn't work.
Comment 6 Abel Cheung 2014-03-17 03:09:10 UTC
Additional suggestion:

* It would be good idea to also provide a list of fonts intended to pass and fail the orthography filter, so that others can also double check.


(This guards against the mistake I have made in previous orth file I submitted)
Comment 7 Akira TAGOH 2014-03-18 03:11:04 UTC
Sure. maybe better not using the kind of 'optional' wording. providing a test case  should be a must. will add it and commit shortly. thanks for the comment.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.