search

notofonts / hebrew

Noto Hebrew
SIL Open Font License 1.1
2 stars 1 forks source link

When using NotoSerifHebrew-Regular.ttf to write ! (exclamation mark) I get tofu #25

Closed avitaleli closed 2 years ago

avitaleli commented 4 years ago

Title

When using NotoSerifHebrew-Regular.ttf to write ! (exclamation mark) I get tofu

Font

'NotoSerifHebrew-Regular.ttf'.

Where the font came from, and when

https://noto-website-2.storage.googleapis.com/pkgs/NotoSerifHebrew-hinted.zip

Font Version

I use it when writing a canvas from a python script running on linux Properties.

  • Linux -- use (Gnome) Font Viewer: open a font and click on Info tab.

OS name and version

Ubuntu 18.04, running with a Python 3.6 scipt

Issue

I am loading this font to be used in a canvas generating a PDF. I am writing an Hebrew sentence ending with !, however the sentence is correctly displayed, however the ! is displayed as tofu.

jungshik commented 4 years ago

The font does not cover the ascii range. You need to use another font (e.g moto serif) along with noto serif Hebrew.

avitaleli commented 4 years ago

Thank you for your email, I think ot would be a problem to mix both fonts. Is it possible to merge both files into one ttf?

On Sat 3. Aug 2019 at 15:46, Jungshik Shin notifications@github.com wrote:

The font does not cover the ascii. You need to use another font (e.g moto serif) along with moto serif Hebrew.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/googlefonts/noto-fonts/issues/1565?email_source=notifications&email_token=ADO2VGSESVH7I3PUSTGGV3LQCWD5DA5CNFSM4IILNCV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3POYJI#issuecomment-517925925, or mute the thread https://github.com/notifications/unsubscribe-auth/ADO2VGSBOPBDVRCBJIJYUX3QCWD5DANCNFSM4IILNCVQ .

jungshik commented 4 years ago

What do you mean by that it's a problem? You can use more than one fonts in your pdf generation code. It's a bit more work, but a lot of folks do that.

If you can't, you can merge noto serif's ascii range to noto serif Hebrew with tools like fonttools.

avitaleli commented 4 years ago

Hi,

I am using a python library that as much as I could see does not enable adding 2 fonts, you have to choose one font when needed (I am still checking this). However I will try to merge as you mentioned.

Thank you, Eli

On Sun, Aug 4, 2019 at 4:40 PM Jungshik Shin notifications@github.com wrote:

What do you mean by that it's a problem? You can use more than one fonts in your off generation code. It's a bit more work, but a lot of folks do that.

If you can't, you can merge noto serif's ascii range to noto serif Hebrew with tools like fonttools.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/googlefonts/noto-fonts/issues/1565?email_source=notifications&email_token=ADO2VGTK6VLDJU56H6Y5JBDQC3S4HA5CNFSM4IILNCV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3QDBUA#issuecomment-518009040, or mute the thread https://github.com/notifications/unsubscribe-auth/ADO2VGWZRTROIWWKPG2DC63QC3S4HANCNFSM4IILNCVQ .

verdy-p commented 4 years ago

Noto is not designed to allow merging scripts. In fact it would be impossible to merge all possible pairs (ore more) of script in one font. Even a single script cannot be used from a single font: Ideographic covers now more than one plane and a third plane will soon be added with Unicode 13.0 (announced recently).

Instead fonts may contain references to alternate known fonts to preferably link with for fallbacks (but generally OSes, or browsers and rendering apps, provide their own catalog of fonts available and allowing user preferences to be used when there are multiple candidate fonts for the same missing mappings; they may use some complex rules for matching not just isolated characters but also clusters and composite characters, or specific variants that may be mapped in one font but not another, and for which the rendering app may have a support; as well these apps may still be able to infer a rendering directly from character properties, notably whitespaces for which they don't need any glyph mapping in any font, except possibly for some of their metrics).

Fonts in fact do not work alone, OSes (or text renderers) just use them as possible sources of data to extend what they can't already handle internally (for example Unicode characters properties do not come from fonts, whatevever their format: TrueType, OpenType, SVG fonts, Webfont, legacy Postcript Type 1 fonts, legacy raster fonts, OS-specific fonts like *.FNT used in Windows or in device drivers for consoles or for old printers...). Each rederer will have its own capabilities depending on the device or user experience they are targetting.

You should think about upgrading your tools to allow specifying list of font families instead of just one. alternatively, may be your OS or software provides a way to declare a "virtual" composite font (this is possible in CSS for example, to be used in HTML, SVG and so on).

There are packages in Python that allow doing that for various output formats, including for generating PDFs (Typically PDF generators are extracting the glyphs they need from various fonts and will build an internal embedded font). If your PDF generator cannot do that, think about using better generators.

I'm in favor of keeping scripts separate because it allows more freedom and better mechanisms for fallbacks and with corect metrics and designs suitable for each script. Latin metrics and Hebrew metrics are very different. And it's much simpelr to design coherent fonts for separate scripts, and then tune each of them for the best coverage (including diacritics, variants, ligatures, kerning and all the required OpenType features for required contextual forms...)

Hebrew has its own complexities that would also complicate the already complex Latin script. And including a partial coverage of Latin would be even worse.

But if one wants to have less fonts, ideally there should be at least 5 families:

  1. all simple alphabetic scripts, and common punctuations and symbols (without any emoji), except Hangul, but including the math symbols.

    2.a. all Semitic abjads

    2.b. all Indic abugidas (possibly merged with the previous in a compound "Complex" family handling required Opentype features, but there may be metrics issues)

  2. all syllabaries (possibly merged with the previous in a compound "Complex" family handling required Opentype features)

  3. Base sinograms (one family for each Hans, Hant, Kore, Jpan style, except ideographs that don't need specialization); Hangul should be in the Kore-specialized font, Bopomofo should be in the Hans-specialized font, Japanese syllabaries should be in the Jpan-specialized font.

  4. All supplementary sinograms not in group 3.

  5. Emojis (due to their specific colorful behavior).

For now these 5 groups can fit in the limits of OpenType (65535 glyphs per font).

But Noto is an free open project, you can still derive these 5 families for the existing base Noto families.

As well there's the complexity of the additional "UI" styles for rendering on display with more compact metrics, needed for some scripts only. Getting a correct naming convention is also still an unresolved issue.

nizarsq commented 3 years ago

@marekjez86 Is this WAI? I don't expect to see (exclamation mark) in NotoSerifHebrew or NotoSansHebrew unless there is a decision to add the basic punctuation marks.

kosmynkab commented 3 years ago

I checked a few scripts and there are inconsistencies in terms of the punctuation added to the glyphset. Also numbers. If that is to be incorporated it's probably a good idea to have it done universally across scripts. Perhaps a replicated set of numbers, punctuation, and special characters?

simoncozens commented 2 years ago

Merging into notofonts/noto-fonts#2257.