On Sat, 2015-11-21 at 18:51 +0100, Gioele Barabucci wrote: > Well, sometimes it makes sense. Suppose for a second that libfreetype is > used for 100% of the font pipeline, from opening and reading the files > to generating the bitmaps to be sent to the display. If you have > integration tests (a la autopkgtest) in every font, then, when you want > to update libfreetype, you can check whether this update breaks any font > somehow: either the tables are not read properly or in your architecture > the sub-pixel hinting is wrong. At that point you can chose to skip that > update. You can do this only if you have tests integrated in the each > font package. FreeType is indeed most of the font pipeline on Debian these days. The problem is that detecting the issues is basically impossible, the best you can do is detect differences in the rendering, but of course there could be legitimate changes. This is done by the Debian installer team by the way. > I understand that. But my counter question is: how you do intend to > proceed with fonts that incorrectly have their embedding bits set? > Asking the upstream to fix the files and re-release or changing directly > the OTF/TTF files? If upstream has text-based source files (like SFD, UFO, Glyphs etc) then we can send them a patch for their source. For the rest I would talk to upstream about the situation. For packages with no upstream, I would probably ignore the problem until there is one. -- bye, pabs https://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part