Evgenii

Hi @Dan C! I must admit, I'm a little confused regarding 'morx' table, as this is an issue recorded on Windows, not MacOS, and none of the fonts tried have 'morx' table at all. In the very first thread the issue was (potentially) narrowed down to PDFlib third-party library that Affinity uses for the pdf export. In the previous thread I attached the pdflib.log which shows that which is consistent with the rendered look. Perhaps you were talking about a different issue in the backlog?

I have been patiently reporting this bug for V1 since 2019, and looks like it was not resolved in V2 (or perhaps I'm doing something wrong?). Glyphs with combining marks that use anchors for positioning (and don't have a dedicated glyph on its own) lose their positioning after the export to PDF. The app itself renders the font correctly. App: PDF:

Oh, fair enough. But still, the lines of the split note are raising on each page separately, the note doesn't get fitted into the new available space. (there also some weird stuff going on with highlighting, but that's secondary). Disallowing splitting still sends the whole note onto the next page.

That doesn't work. The following note doesn't readjust itself and stays split.

So I suppose the best workaround for now would be to make the sidenote 27 manually with a pin, and then restart the automated ones from 28 onwards.

I am trying to understand whether it is possible to adjust the location of the sidenote so that the note frame starts higher than the reference point. In my example notes 27 and 28 start close to each other, and 28 gets split to the next page. This could be easily avoided, if I could adjust note 27 vertically a bit higher. But I did not figure out how to do that. Simply disallowing split notes doesn't help, as it changes the text flow in the main body.

APub version 1.10.5.1342. I have a project with heavy use of combining marks, like in tañkatā̆ or mātā́. The font supports them and they are rendered correctly within APub itself (Fig. 1). However after the export to PDF the anchoring of the marks is incorrect (Fig. 2). Different fonts produce the same result. Word-exported PDF is rendered correctly. A sample file is attached (fonts which should render it correctly are Crimson Pro, Gentium or Vollkorn, for example), as well as resulted PDF and PDFlib log. This is not a new problem specific to this version (here I reported it 3 years ago). However this time I can't use the work around of exporting fonts as curves (which works), as I need text to be selectable in the output. How do people handle this problem when working with languages with diacritics, like Vietnamese? UPD: After playing around some more, it seems that the conversion code puts the diacritics before the glyph it is supposed to get attached to instead of after. (Fig. 1, APub) (Fig. 2, PDF) export-bug.afpub export-bug.pdf pdflib.log

I'm not exactly sure this problem appeared with a new update, but I haven't encountered it before. OpenType substitution is not working if the first character has a mark, that's despite having IgnoreMarks flag Left: how it should be, works without accents; Right: substitution doesn't happen if accent is placed It does work in Word however But to make sure I checked another font I know worked correctly in the past: same problem The ligature breaks if the first character is accented: that should not be happening

I got the trial FontLab and used a minimalistic font, with main GSUB/GPOS features preserved. Now FontLab Metrics Tab renders it correctly: Publisher renders it correctly: Exported PDF not: Printed PDF loses GPOS completely: NotoTeng-Regular.ttf For those interested: a workaround I'm using for now is to add a seperate glyph for each instance of vertical alignment needed. It's a poor solution, but at least it works.

Then why InDesign's export works right, and Publisher's doesn't? I checked the print to pdf option, and it seems that all positionings are discarded with tengwar font. It does work with dieresis sample though, hm.

Yes, exactly 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

What might help with FontLab is to load .fea files directly if possible [attached below] For the FontForge metrics view, there's one screenshot above, but here's one once again GPOS_basic.fea GSUB_test.fea

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

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. 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: No vertical alignment

Sure, here it is. hanging_test.afpub tengparm-medium.ttf

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.

åäö 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.

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. 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.

I'm not sure what you mean by that. Apub renders the font exactly as designed [fontforge metrics view] While exported pdf is objectively different from what I can see in APub with missing vertical positioning.

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

The font I'm using is having an alternative period at the end of the paragraph (three dots vs two dots on the image below; the substitution is defined in opentype feature, three dots period is an .alt glyph). While all standard punctuation is hung without issues, the alternative variations are not recognised. I cannot copy-paste it into glyph section of optical alignment of Character Panel, and I cannot insert it there from glyph viewer either. Is there any workaround?

I'm not sure whether it's a bug, but when exporting a pdf, some GPOS tables get lost. that's how I see text in the Publisher 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.

I use FontBase for managing my fonts, and I had Garamond from Google Fonts. Installing the same very font directly into the system solved the problem, even though I'm not fan of this solution.

Interestingly, if I don't embed the font, the resulting PDF renders it right.

As I mentioned, font reinstallation didn't do any good. Moreover, in other programs, like word, text renders as intended. I believe the export settings are default