Bug #13473

Missing common proprietary Arabic fonts make some PDF documents unreadable

Added by mercedes508 2017-07-16 11:21:18 . Updated 2019-03-23 15:46:29 .

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

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

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.

Subtasks

Related issues

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

History

#1 Updated by intrigeri 2017-07-17 14:47:08

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

#2 Updated by intrigeri 2017-07-17 14:57:39

  • 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 Feature #9956 for details). I don’t know if there would be adverse consequences of such a change.

#3 Updated by intrigeri 2017-07-17 14:58:47

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

#4 Updated by intrigeri 2018-08-18 18:05:44

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

#5 Updated by intrigeri 2019-03-23 15:46:29

  • Status changed from Confirmed to Rejected

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