Re: fonts review wishlish
On Wed, Feb 28, 2018 at 12:41:52PM +0100, Nicolas Spalinger wrote:
> 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.
Actually, if I were to write a new implementation, I'd go your way: a
simple, understandable, easy to tweak script. I'm not shaming your version,
merely its lack of maintenance.
On the other hand, KISS means it's also easy to rewrite it from scratch
instead of repairing the old code.
The layout was imperfect but that's why we're having this discussion: to
gather ideas about what's wrong.
(Alas, I'm behind on other Debian work, thus for now I'm just talking --
which means, feel free to disregard what I say. Words without code carry
little weight.)
> 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.
There's not much that can be done automatically, I'm afraid. But, having
font samples next to each other can be pretty handy for judging quality.
> > 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 ?
The output can change in only two cases:
1. a new version of a package is uploaded
2. the script itself is changed
The old script attempted to avoid repeating work, but did so only at a very
late stage. What I'm proposing is remembering the last seen version and
skipping non-updated packages as the old output will still be valid. This
should result in requiring 2-3 orders of magnitude less work.
And when you alter the code, reprocessing all fonts can be triggered by
hand.
> > * 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...
Not sure how many families are there, it's possible that even one sample per
family would be unviable. Not sure how to improve this without manually
adding some kind of metadata that could be used for grouping, though.
> For a specimen tool, can I suggest ftnsample, fret
> (libfont-ttf-scripts-perl), https://github.com/graphicore/specimenTools or
> similar ?
Hah, I'm more used to libgd-perl or similar low level tools. :p
Using something pre-made looks like less work.
> It would be good to have every font in a package taken into account and
> accessible. The definition of what a family is varies.
Yeah. Noto declares fifteen thousand eleventy nine billion distinct
families (one per file) while a human would call that either three or one.
> 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).
Good point. The main page would still list Latin, though.
And, I for one use as my main proportional font (Firefox' setting, etc)
Aroania (package: fonts-ancient-scripts) for its Latin range, despite that
font having been designed for ancient Greek.
> fontimage (from fontforge) that we used earlier only gave you a selection
> of glyphs it thought represented the font. We want completeness.
I guess there should be per-alphabet lists; each would use a sample for the
alphabet in question.
> > * list of monospace fonts. Can include aspect ratio, etc.
>
> Searchability via queries, filtering and better categories would be great too.
Ie, we'd want a query where you search for fonts matching a given filter.
A single such page would do the trick, and give a nice interface that would
allow implementing searching by a text sample, as requested on the Unicode
mailing list.
Ie, this filter would let you input "ąѫ" to find fonts that include both
archaic Cyrillic and its Latin equivalents.
> 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.
Many font packages are neglected, but I guess the lintian check is enough;
whoever updates such a package will get notified.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.
Reply to: