Re: fonts review wishlish
On 02/28/2018 09:57 AM, Adam Borowski wrote:
> Hi!
> It appears there are calls to revive the fonts review in some way.
>
> Per IRC discussions, the old code is no good, and needs a rewrite from
> scratch, with at most picking some old parts.
Thanks for thinking about doing a better review system :-)
Erm, my very crummy shell script was a simple ad-hoc solution 10 years ago (based on what has previously been done for the games team and fixed up by Paul at times), so I'm glad to hear you want a proper webapp with all the trimmings.
More power to you and everyone else who might help you! Take the core ideas and make it a lot better :-)
IMHO it's a good service to the Debian community to make existing issues with fonts in the archive more visible. Visible bugs are more likely to get attention and get fixed.
(AFAICT most foundries are only now starting to use Continuous Integration with automated testing for their fonts. There are vast discrepancies on font engineering and font quality...)
Upstream might even benefit from these report if done accordingly.
> It'd be good to gather ideas and requirements. So, here's a start:
>
>
> * technical: old cronjob processed every package containing a font on every
> run, causing significant load. Need to do only updated packages (other
> than manually).
Reducing the load is most welcome but you still want the most current reports available.
Only for unstable or testing as well ?
> * short specimens of all fonts on one page: something akin to LibreOffice's
> menu. Obviously one sample per family rather than variant.
That might make a awfully long page...
For a specimen tool, can I suggest ftnsample, fret (libfont-ttf-scripts-perl), https://github.com/graphicore/specimenTools or similar ?
It would be good to have every font in a package taken into account and accessible. The definition of what a family is varies.
The specimen system needs to take into account the non-latin features of fonts too. (Latin specimens for Indic fonts are rather pointless for example).
fontimage (from fontforge) that we used earlier only gave you a selection of glyphs it thought represented the font. We want completeness.
> * list of monospace fonts. Can include aspect ratio, etc.
Searchability via queries, filtering and better categories would be great too.
One of the key features of the old review system was finding duplicate fonts. We have lintian checks now.
Do we still have duplicates bundled flagged? I guess it might still be the case. Sometimes bundles are older versions whereas upstream has released updated versions.
Being able to easily link a report to the relevant BTS entry is quite useful too.
> * script coverage. Hard to think of a good metric: most Unicode blocks have
> a mix of current characters, those used until a 17th century spelling
> reform, and those used by old folks in a language spoken by 1000. Asked
> on Unicode ML, got no good answer despite a long thread. Just dumb
> codepoint count per block for now?
>
> * (requested by Unicode ML): search per character: akin to "fc-list
> :charset=16D7". Preferably multiple characters (show only fonts that
> cover them all). A single input box would be enough.
>
> To implement script queries, we'd need to store all codepoints supported by
> a font. SQL with a row per character per font is inadequate, need to code
> a data structure; 16k fonts with up to 64K characters, most in long streaks.
> Even text representation output by "fc-list : file charset" might be enough.
Can I encourage you to look at pyfontaine https://pypi.python.org/pypi/fontaine/ which can consume CLDR data and already has a lot of font industry support in the form of of published charsets.
Reports from FontValidator would be useful too: https://github.com/HinTak/Font-Validator
Exporting in text format all the core metadata of fonts would be very useful: Fullname, version, copyright, designer, designer URL, Manufacturer, Manufacturer URL, License.
Which ever way you like best but please don't hide that info and only focus on the shapes of the glyphs.
Flagging where the Os/2 fsType is wrong (font embedding) is most useful as well (https://docs.microsoft.com/en-us/typography/opentype/spec/os2#fstype).
Reports from OTS errors are good: https://github.com/khaledhosny/ots
HTH,
--
Nico Spalinger
Reply to: