Project

General

Profile

Bug #13473

Missing common proprietary Arabic fonts make some PDF documents unreadable

Added by mercedes508 almost 2 years ago. Updated 3 months ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Internationalization
Target version:
-
Start date:
07/16/2017
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

Reported by a user, Tails, but in fact many Linux OS are missing some Arabic fonts, making unreadable documents like pdfs (e.g. http://175.45.176.67/ar/book/download.php?4+4002).

While it looks like it's un upstream issue, I feel like it wouldn't be enough to just ask upstream to fix it, when it might be a more sensitive issue for Tails.

Then we have basically two options I can think of:

  • adding those fonts to Tails
  • telling people they have to use .dotfiles feature.

Related issues

Related to Tails - Feature #9956: Consider replacing the additional fonts we ship with Noto Duplicate 08/09/2015
Related to Tails - Feature #15807: Define & apply clear criteria for including dictionaries, fonts and language packs Resolved 08/18/2018

History

#1 Updated by intrigeri almost 2 years ago

  • Related to Feature #9956: Consider replacing the additional fonts we ship with Noto added

#2 Updated by intrigeri almost 2 years ago

  • Subject changed from Tails missing some common Arabic fonts to Missing common proprietary Arabic fonts make some PDF documents unreadable
  • Assignee deleted (anonym)
  • Type of work changed from Discuss to Research

I've had a look at that PDF. The missing fonts are not embedded in the document (usually one wants to embed fonts in PDFs unless they're 100% sure the reader will have them available already); these fonts are included in Windows one can buy them separately. So I don't think we can include these fonts in Tails: sadly there's little we can do directly about documents that require non-free external data to be readable at all.

Now, there might be a workaround: what happens in practice (see Properties → Fonts in Evince) is that fontconfig substitutes the missing font with another one. On my Debian sid system, that's DejaVu Sans. Apparently that substitute font does not support Arabic chars, hence the unreadable document in Evince. I believe we can configure fontconfig to use different substitute fonts, e.g. one that covers many more scripts (I think that's what the Debian Installer does, see #9956 for details). I don't know if there would be adverse consequences of such a change.

#3 Updated by intrigeri almost 2 years ago

(But of course the dotfiles option should be a reasonable, individual workaround. I think.)

#4 Updated by intrigeri 10 months ago

  • Related to Feature #15807: Define & apply clear criteria for including dictionaries, fonts and language packs added

#5 Updated by intrigeri 3 months ago

  • Status changed from Confirmed to Rejected

I wanted to test this with Noto (#15807, #9956) but the link is broken so we have no example document to test candidate fixes with ⇒ rejecting as non-actionable :/

Also available in: Atom PDF