Evgenii
-
Posts
26 -
Joined
-
Last visited
Posts posted by Evgenii
-
-
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:
-
4 hours ago, anto said:
Create different style for this note
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.
-
-
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)
-
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:
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.
-
43 minutes ago, Lagarto said:
So not an Affinity issue but a PDFLib issue?
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.
-
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.
-
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
-
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
-
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
-
On 9/23/2019 at 2:32 PM, Callum said:
Hi Evgenii,
If possible could you provide the font in question and a copy of your document so I can look into this further for you.
Thanks
C
Sure, here it is.
-
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.
-
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.
-
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.
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.
-
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
[fontforge metrics view]
While exported pdf is objectively different from what I can see in APub with missing vertical positioning.
-
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.
-
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.
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
[AfPub] Export to PDF breaks Combining Diacritical Marks
in V2 Bugs found on Windows
Posted
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?