meirsadan / david-libre Goto Github PK

Hey @meirsadan

I've been meaning to release the latest version for quite some time. Apologies for not getting back to you on this sooner.

I'd like to master the fonts according to our spec. We have some old legacy data which can removed. This data is still accessible via git checkout out on the previous commits.

cc @davelab6

Are there any plans to add italic shapes to the fonts?

It would be awesome if you add support for cantillation marks (0591-05AF).

Hey,

I'm guessing you may have left these blank intentionally?

Please see https://github.com/password_reset/AJDXFFGEGQDJ72GFIQPMC526OUCLRBFFMVWWC2LMWJVGM2LOM5SXEQDHN5XWO3DFFZRW63NFMZXXEY3FYKZXI53PL5TGCY3UN5ZF65TFOJUWM2LFMTBLUZTPOJRWKZC7O5SWC227OBQXG43XN5ZGIX3SMVZWK5GC.

The qamats qatan was based on a misunderstanding in David Hadash and the problem continues in David Libre.

Thanks!

@meirsadan After @markhdavid requested GF to update to the latest release, @emmamarichal did a thorough review of the project according to the latest GF requirements, and found a few things where the latest release isn't quite up to the latest high standards we've set for all new GF projects, reported @ google/fonts#6518 (comment)

You can see her work @ https://github.com/meirsadan/david-libre/compare/meirsadan:master...emmamarichal:master?expand=1 & I kindly suggest to PR and merge it in, before continuing :) (Even better would be to take the latest https://github.com/googlefonts/googlefonts-project-template Continuous Integration automation here, although if you aren't familiar with GitHub Actions that could be quite a large effort.)

I was surprised to see for example no @ character in David Libre today in Google Fonts. Since this latin is actually a fork of Gentium, I believe all the missing characters' glyphs can be copied in quickly, and perhaps kerning too. The interpolation compatibility issue may be quite time consuming, though.

I appreciate this may be above and beyond what you can volunteer to do in a hobbyist project, but wanted to post this as an upstream issue that is blocking onboarding the update.

This repo has a gh-pages branch, and then there is https://github.com/meirsadan/davidhofshi which is gh-pages only.

Perhaps making this repo have a single head in gh-pages that has the web stuff and the font development files would be best?

• fsType should be 0
• full name should be with spaces between words Glyphs is smarter than me :) This is fine.

~/src/github.com/google/fonts/tools$ python sanity_check.py ../ofl/davidhofshi/
FAIL: DavidHofshi-Regular.ttf normal/400 fsType expected: 0 fsType: 8 (../ofl/davidhofshi)
FAIL: David Hofshi normal/400 'name' fullName[1] expected David Hofshi, got DavidHofshi-Regular (../ofl/davidhofshi)
FAIL: DavidHofshi-Medium.ttf normal/500 fsType expected: 0 fsType: 8 (../ofl/davidhofshi)
FAIL: David Hofshi normal/500 'name' fullName[1] expected David Hofshi Medium, got DavidHofshi-Medium (../ofl/davidhofshi)
FAIL: DavidHofshi-Bold.ttf normal/700 fsType expected: 0 fsType: 8 (../ofl/davidhofshi)

I'm going over old internal font bug reports and got this from 2020-03-15:

The kamatz in a David Hadash final-khaf is perhaps too high. I am not sure whether Ismar David designed the vowel points or not (I suspect not.)

I include a screen shot of the final word in the second part of the Priestly Blessing (Birkat HaKohanim), in which there is both a dagesh and a kamatz. It clearly looks funny, and can be compared to the Hebrew that comes with Times New Roman and with Arial, where it looks better.

I'll try to see what Helen Brandshaft says, given that it is not clear when the niqud was introduced.

Affected weight(s): All Affected character(s): khaf-sofit (Final khaf) Browser: all OS: all

I spoke with Helen Brandshaft. The situation is a bit more complicated than I realized. The following Unicode glyphs exist:

Unicode Character 'HEBREW POINT QAMATS' (U+05B8)

Unicode Character 'HEBREW POINT QAMATS QATAN' (U+05C7)

Unicode Character 'HEBREW LETTER FINAL KAF WITH DAGESH' (U+FB3A)

It may be that all are correct in David Libre, but doing the complex typesetting in Google Docs or Gmail does not work right, for some reason.

I'm just logging this for future development, I'm not expecting any resolution on this by posting it :)

For a proportional font such as David Libre, set widths for the three so-called Yiddish ligatures

05F0;HEBREW LIGATURE YIDDISH DOUBLE VAV
05F1;HEBREW LIGATURE YIDDISH VAV YOD
05F2;HEBREW LIGATURE YIDDISH DOUBLE YOD

ought to be the same as sums of the set widths for equivalent component characters. E.g., the set width of

05F0;HEBREW LIGATURE YIDDISH DOUBLE VAV

which has as components two VAV characters should be the same as the sum of the set widths of two individual VAV characters, that is, a sequence of two of the following character

05D5; HEBREW LETTER VAV

Users ought to be able to expect that for any properly designed proportional font the spacing of a sequence of yod or vav characters will be correct and the same, whether the sequence is via the Yiddish ligature character or via a sequence of the equivalent components.

This has practical benefits in that keyboards have long varied between operating systems and 3rd-party supplied keyboards in whether they even supply the Yiddish ligature characters as standalone key caps. On the Mac, for example, the native Hebrew keyboard only supplies a keycap for the character combination known in Yiddish as pasekh-tsvey-yudn as the sequence

05F2;HEBREW LIGATURE YIDDISH DOUBLE YOD
05B7;HEBREW POINT PATAH

There is not keycap dedicated to any of the Yiddish ligature characters standalone. It's expected that for Yiddish users will enter only individual vav or yod characters to get the graphic equivalent of the Yiddish ligatures. Some non-default MacOS keyboards and 3rd party keyboards do make the ligature characters available, but the point is, you cannot count on users to use them. Meanwhile, on Windows the traditional default Hebrew keyboard has keycaps for all three Yiddish ligatures. Basically, you cannot control what users enter, whether individual characters or ligatures, and users have every reason to expect that, for a non-fixed-width font, a ligature should look identical to its equivalent sequence of component characters.

Aside: for fixed-width fonts, which are used rather rarely, it's acceptable and expected for these Yiddish ligature characters to take up a single fixed set width while the equivalent sequence of component characters should take up precisely twice that amount. But David Libre is not fixed width, so that has no bearing for this issue.

An easy way demonstrate or test for this issue, take a sequence of digraph characters and place them above an equivalent sequence of component characters, and as long as they start out at the same position, the far-left edge of the last character of the first sequence should align with the far-left edge of the second.

Here's a sample test text:

five X double-vav:
װװװװװ
ten X vav:
וווווווווו
five X vav-yod:
ױױױױױ
ten X individual vavs and yods:
ויויויויוי
five X double-yod:
ײײײײײ
ten X yod:
יייייייייי

Here's how the above text currently looks in Google Fonts preview for David Libre regular at 22 px size (screen shot), with vertical lines added in red to illustrate that the non-digraph characters have different widths than the equivalent digraph characters.

There may be an issue with the "dlig": Yod-Vav turns to Vav-Yod

Please update the files in https://github.com/meirsadan/david-hofshi/tree/master/01_originals/davidx_vfb_resize to remove any names from filenames or internal metadata that may be claimed by others :)

It would be useful for the repo's front page (README.md) to also include an explanation of how David Libre differs from David CLM (the Culmus font).

@meirsadan

Hi Meir,

The Google fonts team would love to see a variable fonts version of ‘David-Libre'. They have commissioned us @TypeNetwork to work on upgrading a number of font projects to be variable fonts with a single weight axis.

In order to achieve the highest quality and most efficient long term results we will be converting the source data from Glyphs to UFO. The new source data will be generated in the RoboFont environment using fontmake and ttfautohint. There has been progress on tools to make an easy path to move between the Glyphs and Robofont environment.

During the process we will be looking to improve any errors while preserving how the font appears and renders on different platforms.

We have started by making a fork off of this git repository. The upgrade will be completed for you in the near future. When the proposed final font is approved by Google will you accept a pull request?

To confirm, is the .glyphs source file on this git repository the most current data?
DavidLibre.glyphs

We hope this answers some of your questions about the process. Please let us know if you have any additional comments.

Best Regards,

Jill Pichotta
Vice President
Type Network
[email protected]

Similar to https://github.com/vaishnavimurthy/Akaya-Telivigala/ and https://github.com/girish-dalvi/Baloo/ it would be great to have a PNG image showing a preview of the design, stored in /documentation/sample.png, and shown inline in README.md

This font renders digraphs double-yud (Unicode Character “װ” (U+05F0) ; Name: Hebrew Ligature Yiddish Double Vav) and double-vov (Unicode Character “ײ” (U+05F2) ; Name: Hebrew Ligature Yiddish Double Yod), primarily used for Yiddish, such that nikud that's supposed to be centered under a character get put under the second subletter of the digraph. So a nikud like pasekh, tsere, segol, et al, is centered under the 2nd yud of double-yud and under 2nd vov of double-vov. That's wrong. Nikud is supposed to be centered with respect to both elements of the digraph. That's how these work. That's the whole point of why you need these digraphs. If you wanted the nikud centered under the second character of the digraph, you wouldn't need a digraph: you'd put out two separate characters with the nikud following the second character in the character sequence and unambiguously intended to be centered under that second character.

Here's a sample text for which I'll attach a screen shot of Google Fonts preview showing wrong rendering: װֶעלְכֶע | װֶעלְן | זײַן | רײַך