[Pkg-fonts-devel] location of woff files

Tue Apr 4 14:25:08 UTC 2017

Quoting Nicolas Spalinger (2017-04-04 13:10:41)
> On 04/04/2017 12:14 PM, Jonas Smedegaard wrote:
> > Quoting Nicolas Spalinger (2017-04-04 11:32:59)
> >> On 04/04/2017 09:20 AM, Jonas Smedegaard wrote:
> >>> Quoting Bobby de Vos (2017-04-04 00:22:11)
> >>>> Where should .woff files be installed? For the 
> >>>> fonts-sil-andikanewbasic package, .woff files are installed to
> >>>>
> >>>> /usr/share/fonts/woff/andikanewbasic
> >>>>
> >>>> One user encountered a problem using XeTeX specifying the font as 
> >>>> Andika New Basic, I guess fontconfig found the .woff file before 
> >>>> the .ttf file for this font, and XeTeX could not process the 
> >>>> .woff file. It seems better to me to have the .woff file under 
> >>>> the documentation for the font. For NRSI fonts, this would work 
> >>>> well, as NRSI ships two files
> >>>>
> >>>>  1. AndikaNewBasic-webfont-example.html
> >>>>  2. AndikaNewBasic-webfont-example.css
> >>>>
> >>>> that use a .woff file in the same directory at the .html and .css 
> >>>> files to show an example of the font.
> >>>
> >>> Please put woff files below /usr/share/fonts/woff
> >>>
> >>> And please file a bugreport against packages choking on the 
> >>> existence of woff files in a generally discoverable place: That is 
> >>> not specific to your package.
> >>>
> >>> Similar for eot fonts.
> >>
> >> I don't see anywhere support for these formats in fontconfig.
> >> What did I miss? 
> > 
> > Font packages have more uses than via fontconfig.
> 
> And yet /usr/share/fonts is what is defined in fontconfig's font path 
> in /etc/fonts/fonts.conf
> All fontconfig-enabled apps go look for the resources there. As 
> expected.

Right: fontconfig uses that path.

I don't follow what is the issue. Are you implying that *only* 
fontconfig sould use that path, or what are you saying here?

> >> These formats are web-native, why are they added to the outside of 
> >> a webserver DocumentRoot?
> > 
> > Font packages are not targeted one documentroot: Each package (or 
> > user-provided) documentroot can symlink a font from a shared 
> > location.
> 
> >> Why should we ship these fonts when GUI apps are looking when they 
> >> are only useful for webapps ?
> > 
> > Font packages are not exclusively for GUI apps nor web apps.
> 
> The issue, as I see it, is that we're putting web things where only 
> GUI apps have been looking for a long time.
> A separate web formats FHS area sounds better to me. And less likely 
> to cause unexpected results.

I do not recognize a general¹ problem here.

It seems counter-intuitive to me to restrict /usr/share/fonts to non-web 
font formats. Yes, it is a workaround for applications choking on web 
fonts, but does not solve applications choking on other font features - 
e.g. ttc container or certain OpenType features.

Such applications are buggy, and such bugs should be fixed, not worked 
around by hiding such fonts from fontconfig.

> >> How about they are put elsewhere instead of breaking existing apps?
> > 
> > Other font packages already use the path /usr/share/fonts/woff - so 
> > if that breaks XeLaTeX or other programs, then we have a bug 
> > already.  Therefore please file the bugreport if that path cause 
> > problems, no matter if then using that path in any new package.
> 
> Which particular apps require that woff be shipped by default in a 
> fontconfig-enabled path?

Fontconfig is fundamentally not "required" - any and all application can 
have fonts spoonfed.

If consumers of fontconfig generally use only certain font formats, then 
let's report and have fixed the _bug_ of fontconfig discovering and 
promoting fonts in other formats.

I do not believe fontconfig to be buggy here, so I will leave it to 
others to file such bugreport.

> >> AFAICT this woff inclusion is only a recent trend, isn't it? 
> > 
> > Relatively, yes.
> > 
> > 
> >> https://webapps-common.alioth.debian.org/draft/html/ch-issues.html#s-issues-fhs
> >> says /usr/share/PACKAGE/www or /usr/lib/PACKAGE
> > 
> > Makes sense for webapps to define a path for that specifically - they 
> > can then symlink _shared_ resources like fonts and javascript and css 
> > from respective _shared_ paths for those.
> 
> So there is a precedent of putting them in a dedicated separate folder 
> (and not say the fontconfig folder) and symlinking them from there.

The common thing for a webapp is to place its fonts inside its own 
project - i.e. to *duplicate* the fonts for each and every webapp.  
Similar for css and javascript.

In Debian we call that "convenience copies of shared code" and actively 
deduplicate when packaging, by placing shared code in shared paths and 
symlinking as needed.

 - Jonas

¹ I do recognize potential _specific_ problems of some applications 
blindly assuming that all results provided by fontconfig are usable for 
them, where I believe each application should validate results 
themselves.

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/20170404/d9e298de/attachment.sig>