Jump to content
Evgenii

Marks positioning in exported pdf

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.

Share this post


Link to post
Share on other sites

Quite interesting. I reproduced this in InDesign and QuarkXPress and it seems to work there (see attached files). But are you supposed to type these characters from the keyboard, and use ligatures and diacritics, as the way I produced these characters was just using negative kerning and character shift with single glyphs, which is a bit hard way to write in Elven tongues (though I am not sure if there is even supposed to be an easy way...)

Additionally, In Affinity Publisher, the Glyphs panel does not show the currently selected character, which makes it a bit awkward to use these kinds of custom fonts in this app.

With regular fonts character shift and negative kerning seems to work fine in Publisher, but not with this font for some reason.

fontproblem_quark.pdf

fontproblem_id.pdf

fontproblem_apub2.pdf

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Wow, I educated myself a bit in Tengwar, and can now see that Affinity Publisher is the only one of these three page layout apps that actually renders the font correctly! The way I composed these in InDesign and Quark was, as mentioned, manual glyph composition by using negative kerning and shift, which is of course all wrong!

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

This is how the input looks in InDesign (CS6). The text input requires "Mark Positioning" and "Localized Forms" OpenType features checked, to display the combined forms. But they do not align properly, as they seem to do in Affinity Publisher. QuarkXPress 2018 does not list these OpenType features and I cannot input this there.

Have you any tool where you can test whether the font actually behaves correctly? i opened this in FontLab VI (6.1.4.7044) but when I compile the features set get an error on line 288 in mkmk table, "markClass y <anchor 0 -128> @;", the output window saying that "@" is invalid token.

My knowledge of OpenType is very elementary so I have no clue where to go from there but the compile error seems to prohibit me from testing the feature set in FontLab Preview panel or Text window, and showing or even listing any of the supported features like lcl, mark and mkmk tables there. 

Since Affinity Publisher renders the input correctly, and can convert it to curves properly, there is of course a chance that this just gets rendered badly in the PDF viewer, but I have tested many, and it does not seem so.

tenwar_id.thumb.jpg.0aca566f71e5bc4291c9c159d386ddcf.jpg

Share this post


Link to post
Share on other sites

Related to this, I installed Nadyezhda SL One from Adam Twardoch's site at http://www.twardoch.com/fonts/, which has all OpenType features included to allow easy testing of any application's OpenType support, and ran a test on Affinity Publisher and InDesign.

Both apps seem to have more or less the full set of OT capabilites supported (not all can be simultaneously enabled because there are mutually exclusive features), but intrestingly Affinity Publisher does not seem to have them all listed in the UI. E.g., the positional marks and localized forms specific to this font (Tengwar Parmo), shown here as tables LOCL, MARK and MKMK, are not listed in the UI and cannot be turned off if wished. I wonder why?

opentype_capabilities_apub.jpg.6271ce83428b8eb50c0bcb3a9ffbf1e1.jpg

 

opentype_capabilities_id.jpg.73cabd3348e85452f0f219da2c1fd6e6.jpg

 

 

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
2 hours ago, Evgenii said:

I only tested the font in FontForge and Publisher.

Ok, thanks for all the information. I need to get familiar with FontForge, I just fiddle a bit with fonts (though I have lately become interested in combining programming with fonts, e.g. to produce randomness, especially when combining with web), so I have sticked with FontLab Studio, the first version of which I purchased already years ago. But it seems that at least from programming perspective interesting things happen also (and perhaps mostly) elsewhere (at least on macOS, Glyphs and Robofont seem to be the most popular, and FontForge seems also have a good scripting support). 

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Sorry for my ignorance, but I'm not sure if InDesign (at least CS6) allows to define the typography script (?). In Affinity Publisher this can be done (along with typography language), but it does not seem to have any difference whether Latin, Auto or Default is used (for this particular font), not also when the pdf is exported.

But if you managed to produce different behavior with the test font you mentioned, it is worh testing if such definitions would resolve the problem with Tengwar font, as well. I can help you with testing if there is any need. Btw, when opening the Tengwar font in FontLab, the font cannot be identified (filtered out) with any writing system (other than "Any"), so the font's writing system is not identified with "Latin". Don't know if it is even supposed to be, but I was just wondering whether there needs to be a match with "Latin" in GPOS, and the writing system of the whole font.

Share this post


Link to post
Share on other sites
41 minutes ago, Lagarto said:

it is worh testing if such definitions would resolve the problem with Tengwar font

It objectively didn't resolve it though; ä got exported with dieresis god knows where even though it is rendered right in Publisher

Share this post


Link to post
Share on other sites

It is hard to find apps that support position marks and localized forms. Pages seems to do that, but it also renders this differently from Affinity Publisher, and also differently from InDesign:

hellanore_pages.png.78b6a3d61e65ba2ddbc58ec846ca5151.png

It is interesting that Adobe apps behave differently from Pages, which renders the second but last character similarly as Publisher (but which is omitted completely in Adobe apps).

The way the forms are combined in this font is very interesting, and it is a clever way to input a complex script and foreign tongue phonetically. E,g, the way the second character is composed, getting a three key input, is peculiar and fun (at least in Western perspective). But I wonder whether there is some rule as for validating how successive keys can be grouped, and how the separateness of key input is resolved? The fact that these three apps, Affinity Publisher, Adobe InDesign and Pages each render the font differently, and the fact that the PDF produced from the Affinity rendered text is also shown differently, suggests that there is some irregularity in the way these tables are encoded in this font.

(The fact that the font does not compile in FontLab Studio, and that the FontLab documentation gives different syntax for encoding e.g. the MKMK table and anchor pairs, than shown when operning the .TTF file, suggests that there can be multiple ways to encode this information; or perhaps it is just a question of FontLab's attempt to read (de-engineer) the information included in the font, and problems resulted from inadequacies in this process.)

Note from the attached pdf that if I create a PDF print output (using Adobe Acrobat Printer) from the text created in Affinity Publisher, it is also rendered differently from the PDF created by using Affinity Export. This is pretty close to the way Pages renders the text, except for the first character. 

I suppose these features (LOCL, MARK, MKMK) are used typically in Asian scripts (kanjis etc.) so they are definitely in good use, so it is unlikely that the feature set would not be well supported at least in Adobe apps. But it would be very interesting to know the reason for these differences.

Is it possible to type in "Hellanóre" in FontForger in some preview window and see that the text renders correctly there? Or is Affinity Publisher the only app where you have tested the functionality of the input?

tengwar_apub_printadobe.pdf

Share this post


Link to post
Share on other sites

Sorry, missed it there. This is getting really interesting, as I thought the problem was that FontForge can show this with the actual source code of the font, while it can handle this directly when just opening the font! So it is definitely not a question of needing to reverse engineer anything...

Please find attached the features exported when I open the font in FontLab Studio. The compile fails at line 314 in this combined export list, at the first marktomark  

markClass y <anchor 0 -128> @;

...because FontLab fails to put anything after the at sign (that is anchor the glyph class to anything).

Was I supposed to completely replace the current feature set with the ones you attached above? I tried both by first erasing all features, then importing, or just importing and allowing FontLab to replace existing (equivalent tables, I suppose, leaving untouched any of the other tables), but both times just get a bunch of error messages, like this:

"@DOWNTEHTA_DOWNTEHTA_LOOKUP" would be a 16th. <Font> No more than 15 different class names can be used with the "lookupflag MarkAttachmentType <class name." statement "@ALDA_DOWNTEHTA_LOOKUP" would be a 16th. 

-- --

<Font> aborting because of errors

I wonder if I'd need to import the classes first to get this working.

Anyway, perhaps you can make something of the exported features list. It appears as if FontLab simply just fails to read the font information, expecting the feature tables to be encoded differently.

I just used up my trial periods with Robofont and Glyphs but I'll try to install them on another computer to see how they open and handle this font. Quite useful learning process and introduction to internals of OpenType for me, but I'm genuinely interested to see why so different renderings in different apps, and on top of that, different PDF renderings. 

 

tengparm-regular.fea

Share this post


Link to post
Share on other sites

I downloaded the trial (or Light) version of OTM and there are no problems displaying correctly the mark positionings:

 

tengwar_otm.jpg.a2c808d2173a83e9bc6cc385665f2be9.jpg

I do not know if this tool has an option to input text and try how combinations of glyphs using mark positioning and local forms behave, as the problem does seem to be rather in input than the table data.

The Light version allows you to export OT tables which might be useful when comparing with feature tables created in FontForge. I'll try if importing OTM exported feature tables in FontLab Studio makes any difference there.

 

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | 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.