[Pkg-fonts-devel] location of woff files

[Nicolas Spalinger]

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)
>>>> Greetings,
>>>>
>>>> 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. 

>> 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. 
 
 
>> 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? 

>> 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. 


>> About EOT, do you realize eot is a obsolete 
>> platform-and-browser-specific format (with DRM features) only 
>> supported by older versions of IE?
> 
> I was unaware of that.  Thanks for mentioning.
> 
> When that particular browser for that particular platform no longer 
> receive any support from any Debian packages, we can stop mention 
> /usr/share/fonts/eof as the proper shared path for such fonts.  Until 
> then it makes sense to place such fonts there rather than at other 
> places in the system.

It's a little surprinsing that IE would be a key part of Debian's FHS recommendations...

> 
>  - Jonas
> 

-- 
Nicolas