font face src with query not found on filesystem

[arthru]

When using fontawesome from filesystem, the font is not displayed in generated pdf.

Fontawesome uses the following declaration :

@font-face {
  font-family: 'FontAwesome';
  src: url('../fonts/fontawesome-webfont.eot?v=4.7.0');
  src: url('../fonts/fontawesome-webfont.eot?#iefix&v=4.7.0') format('embedded-opentype'), url('../fonts/fontawesome-webfont.woff2?v=4.7.0') format('woff2'), url('../fonts/fontawesome-webfont.woff?v=4.7.0') format('woff'), url('../fonts/fontawesome-webfont.ttf?v=4.7.0') format('truetype'), url('../fonts/fontawesome-webfont.svg?v=4.7.0#fontawesomeregular') format('svg');
  font-weight: normal;
  font-style: normal;
}

In that cases, the query part (following ? in src url) is interpreted as part of the filename, which is not.

As a fix, I would suggest to improve weasyprint.css.descriptors.preprocess_descriptors by removing the question mark and what follows in src url when base_url starts with file://

[arthru]

An example to reproduce the problem :

wget https://fontawesome.com/v4.7.0/assets/font-awesome-4.7.0.zip
unzip font-awesome-4.7.0.zip

And the weasyprint code :

from weasyprint import HTML, CSS
from weasyprint.fonts import FontConfiguration

font_config = FontConfiguration()
html = HTML(string='<i class="fa fa-smile-o" aria-hidden="true"></i>')
css = CSS(filename='font-awesome-4.7.0/css/font-awesome.min.css', font_config=font_config)
html.write_pdf(
    '/tmp/example.pdf', stylesheets=[css],
    font_config=font_config)

[arthru]

This pull request proposes a fix for this : #688

[liZe]

Dirty problem… Thanks for the example.

I'm afraid the problem is a little bit more complex, and is actually in Python:

>>> from urllib.request import urlopen
>>> urlopen('file:///tmp/font-awesome-4.7.0/fonts/fontawesome-webfont.ttf')
<addinfourl at 140212679104720 whose fp = <_io.BufferedReader name='/tmp/font-awesome-4.7.0/fonts/fontawesome-webfont.ttf'>>
>>> urlopen('file:///tmp/font-awesome-4.7.0/fonts/fontawesome-webfont.ttf?test')
Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1473, in open_local_file
    stats = os.stat(localfile)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/font-awesome-4.7.0/fonts/fontawesome-webfont.ttf?test'

This behavior is actually OK when reading RFC 8089: query strings are not defined with the file scheme.

Unfortunately, browsers (including curl) allow query strings with the file scheme, probably for retro-compatibility reasons. So… It's hard to choose between following the RFC or following the browsers.

I've open an issue on Python's bug tracker, I'll wait for their answer before deciding what to do.

[Tontyna]

@arthru - on Non-Windows you could provide your own url_fetcher_function (which cuts off the query string) to WeasyPrint's HTML().
Edit: This fetcher function will be called for other URLs within the document, too.

@liZe - on Windows we load font files via open() to to circumvent URLError: <urlopen error file on local host>

[liZe]

on Non-Windows you could provide your own url_fetcher_function (which cuts off the query string) to WeasyPrint's HTML().

Yes, and if Python doesn't want to fix the "problem" in the standard library, that's probably in the default fetcher that #688's code should be applied.

on Windows we load font files via open() to to circumvent URLError: <urlopen error file on local host>

Oh, I see what's in font.py… That's a different, unrelated problem: in font.py, we transform a filename (given by Pango) into a file: URI, but the 'file://' + filename hack for UNIX-like systems doesn't work for Windows. The real solution is to use pathlib and remove the special case for Windows. urlopen is supposed to work on Windows, even with file: URIs.

[Tontyna]

Stupid me, of course only external url() font sources are endangered by query strings.

the 'file://' + filename hack for UNIX-like systems doesn't work for Windows.

Because on Windows the hack would be 'file:///' + filename with 3 slashes.

[liZe]

Because on Windows the hack would be 'file:///' + filename with 3 slashes.

And I'd rather rely on pathlib for that 😉.

[liZe]

And I'd rather rely on pathlib for that .

@Tontyna could you please check that 56ec1cb also works on Windows?

[Tontyna]

@arthru's FontAwesome example works for me on Win7, produces smiling fa-smile-o from the WOFF font file.

As expected fontconfig.FcConfigAppFontAddFile() refuses to accept the EOT and the WOFF2, giving error Failed to load font.

@liZe to distinguish a fetch/open(url) error from a FcConfigAppFontAddFile error I suggest to log different error messages, eg "Failed to load font from url" vs. "Fontconfig failed to add font".