Skip to content
This repository has been archived by the owner on May 22, 2024. It is now read-only.

System Fallback for Cyrillic, Hiragana, Katakana, Han etc. #111

Open
tpreusse opened this issue May 11, 2018 · 2 comments
Open

System Fallback for Cyrillic, Hiragana, Katakana, Han etc. #111

tpreusse opened this issue May 11, 2018 · 2 comments

Comments

@tpreusse
Copy link
Contributor

tpreusse commented May 11, 2018

http://localhost:3007/2018/05/11/russlands-staatsfeind-nummer-eins.pdf (prd)

on local version (@react-pdf/core@0.7.7-24)
screen shot 2018-05-11 at 11 07 51

on prd version (@react-pdf/core@0.7.7-22)
screen shot 2018-05-11 at 11 22 35

on the web
screen shot 2018-05-11 at 11 08 47

Пенсионеры из "Отрядов Путина" сожгли фото Павла Дурова

Ultimately we do need font manager. As long as we're SSR-Rendering we should get the benefit of being able to access system fonts for such cases.

@diegomura
Copy link
Contributor

diegomura commented May 11, 2018

Do we need font-manager or just being able to just pass many font-families on styles? such as the web?
The thing about font-manager is that I cannot add it to the react-pdf substitution engine because it’s not installable on the web. We can either follow a solution like the one above, or make a custom republik font-substitution engine

@tpreusse
Copy link
Contributor Author

tpreusse commented May 11, 2018

I think it should be an API like this:

import { Font } from '@react-pdf/core'

const substitutionCallback = (postscriptName, char) => {
  // get a font instance
}

Font.registerSubstitutionCallback(substitutionCallback);

This would follow internally to fontSubstitutionEngine via the LayoutEngine.

@react-pdf/node could then set a default substitutionCallback powered by font-manager. On the web someone could implement this callback to feed in a large fallback font, but most will not want to because of the associated size.

being able to just pass many font-families on styles?

Not sure how important that one is. Generally I wouldn't want to specify Helvetica everywhere because 0.1% of my documents may contain a odd Cyrillic or Han line.

I also realised that it makes sense to fallback to the system Helvetica after trying the asm Helvetica, since the asm file has a small subset of what probably most system Helvetica have. The original substitution engine probably had this strange loading from font-manager in many or most cases because of that.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants