Jump to content
You must now use your email address to sign in [click for more info] ×

Marks positioning in exported pdf


Evgenii

Recommended Posts

I'm not sure whether it's a bug, but when exporting a pdf, some GPOS tables get lost.

2019-09-22_12-31-28.png.806bc4c2f88450a8fdce535e3dde36c0.png

that's how I see text in the Publisher

2019-09-22_12-31-36.png.417daf9215667ecdf35e6b5403ce2b2e.png

and that's how it gets exported to pdf. For the most part (I checked in a large sample text) marks are where they belong, but those two (over the first letter and under the second) are not. As far as I could see those two [and those belonging to the same tables] are the only ones exported wrong.

Transforming text into curves works, but is suboptimal. Below is a sample file and the font in use.

tengwar_test.afpub

tengparm-regular.ttf

EDIT: actually, all marks which have vertical positioning lose it after export.

Link to comment
Share on other sites

1 hour ago, Lagarto said:

But are you supposed to type these characters from the keyboard, and use ligatures and diacritics

Hi there! The font uses opentype feature tables for mark positioning, so it's sufficient to simply type a transliteration using a keyboard.

Link to comment
Share on other sites

3 minutes ago, MikeW said:

The display in APub is wrong, the pdf is almost correct.

I'm not sure what you mean by that. Apub renders the font exactly as designed

2019-09-23_07-55-16.png.224ef31740038cdcd2ec4946904e37c6.png

[fontforge metrics view]

While exported pdf is objectively different from what I can see in APub with missing vertical positioning.

Link to comment
Share on other sites

9 minutes ago, Evgenii said:

I'm not sure what you mean by that. Apub renders the font exactly as designed

2019-09-23_07-55-16.png.224ef31740038cdcd2ec4946904e37c6.png

[fontforge metrics view]

While exported pdf is objectively different from what I can see in APub with missing vertical positioning.

Then FF is also wrong.

The underbar.lamde (the straight line in the middle of your l character, is suppose to be underneath it like so:

Capture_000233.png.89fe4a634675b76fd68a0376bcf86d17.png

You can clearly see where the mark is in the top part of my screen shot (the red cross) and it is positioned under the l properly.

Link to comment
Share on other sites

11 minutes ago, MikeW said:

The underbar.lamde (the straight line in the middle of your l character, is suppose to be underneath it like so

Font has a GPOS table which shifts all down marks up into inner area of the letter, so surely FF and APub then render it according to the design.

2019-09-23_08-14-25.png.24f93cffa9ed71b7c813674efe06d9ce.png

In case you mean that the down marks should be below and not inside lambe when writing tengwar, then well, it's somewhat irrelevant to the export issue.

Link to comment
Share on other sites

6 minutes ago, Lagarto said:

Yes, true, it somehow messes this up when exporting. I wonder how these chracters are different if you compare them with simple diacritics like åäö, which also include vertical shift?

åäö are different in a way that they typically have their own glyph slots and are encoded with links to both glyphs positioned together, right? While here a letter and a mark are two separate symbols which positions are encoded in opentype tables.

Link to comment
Share on other sites

1 hour ago, Evgenii said:

Font has a GPOS table which shifts all down marks up into inner area of the letter, so surely FF and APub then render it according to the design.

2019-09-23_08-14-25.png.24f93cffa9ed71b7c813674efe06d9ce.png

In case you mean that the down marks should be below and not inside lambe when writing tengwar, then well, it's somewhat irrelevant to the export issue.

Yep. My bad. I looked for that combination of marks and couldn't find it.

Sorry! Mike

Link to comment
Share on other sites

As per opentype specification, LOCL and MKMK tables are on by default.

However, I did notice that Publisher doesn't allow some tables, for example CCMP. It should be on by default, but for some reason is not, and since it doesn't appear in UI, can't be set on at all.

For the FontLab error, I see the line in .fea file where it happens, but I don't see anything wrong with it. I only tested the font in FontForge and Publisher.

For why it behaves the way it behaves in other commercial products, I wouldn't tell, because I don't own them to do the testing.

Link to comment
Share on other sites

I poked a little with a simpler example: I made a font with three characters - a, low dieresis, and ä; I added GPOS to shift low dieresis up when placed after a to match how it looks for ä. Idea is, that if vertical positioning works correctly, both a with low dieresis and ä will be looking the same. And here's what I found:

- first, even though GPOS is defined for both latin and default languages, it only works when Typography script in Language tab is set to Latin; it might be a mistake in the font (well, it was really just a 'done in 2 minutes' sample), but it might be a reason why the positioning didn't work in InDesign, if you had to switch the typography script there.

2019-09-24_17-26-16.png.b171717c4b5b7fee07f1b8e0a98a9e3f.png 2019-09-24_17-26-33.png.193a72514e3f63aa5bb2482bc7684172.png

Left: Typography script Auto; Right: Typography script Latin

- second, and more importantly, when i export into pdf (with Latin script, thus both letters look the same), I get this:

2019-09-24_17-27-34.png.e41f4d29274c63535dc4fb8b6b3af537.png

No vertical alignment

Link to comment
Share on other sites

6 hours ago, Lagarto said:

Was I supposed to completely replace the current feature set with the ones you attached above

Yes, exactly

3 hours ago, Lagarto said:

might be useful when comparing with feature tables created in FontForge

I didn't create the features in FontForge, I wrote them in seperate files, that I attached above, according to specifications and imported in FF. If I export these features from FF, the syntax I believe will be different.

But I feel like the topic is deteriorating: the problem was with the Publisher render differing from exported pdf. 

Here's a minimalistic example font I have used above, stripped off all unnecessary features which might be causing you problems in different software: it has only two glyphs defined - a for 'a' and b for 'dieresis mark', as well as mark table to place it above.

vertical_test.ttf

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.