LibreTraining

Looked at the Backtalk Sans. I see what you mean. The curly quotes are much smaller than the regular apostrophe and quote. The visual weight is just off.

I am curious ... what font is it?

I guess I made an assumption which is not correct. Was messing with the fractions a few days ago and they do work that way. So I assumed that like other apps APub is doing the same for other legacy ligatures. But they are not there in the auto-correct settings. Tried to test your doc above and replicate the results. Getting some different results (and some odd results). I suspect it is because you used ArialMT which is a font flavor I do not have. I have the standard Arial that came with Win7, (and other versions from Win10, 8.1, XP, etc). I also have the full Arial MT Pro family. These different sources have very different ligatures features. I would like to test the exact ArialMT version that you used. Would it be possible for you to PM it to me for testing?

The "fi" ligature is one of those old legacy ligatures which are included in most (all) Unicode fonts. Applications like APub, LibreOffice, Word, etc. usually automatically replace these using an auto-correct feature. So disabling OpenType standard ligatures will not turn them off. You can disable auto-correct, or just remove those from the auto-correct dictionary. Another workaround is to insert a zero width non-breaking space between the characters to prevent the ligature from being applied.

I think you missed the point. That font is limited to just the "legacy frac feature" - it has no OpenType feature code for anything else. The only fractions it can produce are the three listed. There is no support for anything else such as the expected OpenType arbitrary fractions. So having an OpenType Fractions feature as implemented in that font is misleading the user at best, and in my opinion just stupid. Imagine a user buying an OpenType font which lists "frac" as a feature - and then you find-out it is nothing more than three ligatures replaced by the three legacy fractions. Every antiquated word processor can already produce those few fractions. Wadda rip-off.

I was thinking that it was an all or none decision. Then I was reading this again (which is what you refer to) That basically says we don't mix the two (real and fake) as you mention. And that both ways are available. So this does now have me wondering why the OpenType superscripts are not available in Typography. Appears to be a font issue as Adam mentions. Anybody from APub want the font for testing?

Hmmm .... that also enables the missing SS01 alternates. But this may also be an unintended interaction with the enabling/disabling features based on the existence of OpenType features (as Walt mentions above). Why have an OpenType superscripts feature in the font when the only characters supported are the three Unicode legacy characters - onesuperior, twosuperior, and threesuperior? It is my understanding the changes Walt mentions above will disable certain features when the assumed more complete OpenType feature is present. In this case should APub disable the fake superscripts feature for just those limited characters? Is APub confused by this? (a bug?) Why have an OpenType fractions feature in the font when the only characters supported are the three Unicode legacy characters - onehalf, onequarter, and threequarters? Most applications like APub, LibreOffice, etc. are going to replace those using an auto-correct feature. In this case it makes sense to me that APub does not even show Fractions in the Typography panel. I think most users who see an OpenType fractions feature in the Typography panel will expect support for full OpenType arbitrary fractions, and not having that would be confusing. But the stylistic set 01 not being there does confuse me. In this font SS01 is alternate versions of the "a" and "e" characters (and all accented versions). Changing the Typography Script to 'Default' in the Language section of the Character Panel as AdamW recommends above makes the stylistic sets and alternates, etc. then appear in the Typography panel. Is that a font issue? Or an APub issue? Or both? So there appear to quite be a few interacting issues, and possible bugs, and odd font problems/issues. I'm soooo confused.

Recently they made changes to how the fonts are read - it has been mentioned in a few other posts. So I am wondering if that change has affected the reading of these fonts causing some conflicts which corrupt the font cache. If it were me the first thing I would look at is the fonts themselves. And other fonts in the family which could be a potential conflict. What you might try is to only have just the few fonts you are actually using installed. If the Light font works when installed alone this points to a conflict.

What is the source of these fonts? The font names in the PDF do not correspond to either the LT Std or LT Pro fonts. So I am wondering if these are a bad conversion or some other source. Often these fonts have naming problems within the fonts which can cause conflicts. There are no naming issues with the LT Std fonts that I have; don't know about the LT Pro fonts. The only way anyone can troubleshoot this issue is to have the actual fonts and a test doc. The first thing I would do is look at the entire font family to see if there are any naming issues. Simply fixing the font names may eliminate the problem. The APub devs will need the fonts and a test doc.

At first this appears to be a bug, but it may be an issue with the font. The Basier Square v1.000 that I have has OpenType superscripts for three numbers - 1, 2, and 3. So your example above showing "1" should work. I tested the superscripts in a font editor and they worked as expected. I installed Basier Square - Regular and tested in APub 1.7.0.257. The superscripts do not work. Just as in your screenshot above no Superscript option appears in the Typography panel. But it may be a problem with the font. The stylistic set 01 also did not work. And this is on the same test page where these features are working in some other fonts. Perhaps you can provide a text doc and the fonts for the developers to test.

Can you check your Windows fonts directory and see if you have any duplicate fonts installed? For example: arial.ttf and arial_0.ttf, etc. Have to use a tool which allows you to see the actual files, not the Windows font list interface. You seem to have a mix of Arial fonts from Win10 and earlier Windows versions. Some of your Arial fonts are not included it Win10. So I am wondering if some duplicates got installed and that is confusing the new font reader in APub. The version of Arial (R/I/B/BI) included in Win10 is v7.000 - so you can check that too. Have you installed the Arial Nova supplemental fonts for Windows 10? You didn't mention it so I thought I would confirm yes or no. On Windows 7 x64 I am not having any issues in APub with the same list of various Arial fonts.

My head is spinning ... Tested with fonts Calibri-Light, Bookmania, and Vollkorn. As expected the standard ligatures which are Unicode points (fi, fl, ffi, ffl, etc.) always work. LibreOffice > Export to PDF (subset fonts) > Open PDF in APub. The standard ligatures all seemed to import OK (even the non-unicode ligatures). The discretionary ligatures all did not import correctly. LibreOffice > Print to PDF printer (embed full fonts) > Open PDF in APub. The standard ligatures all seemed to import OK (even the non-unicode ligatures). And all the discretionary ligatures all seemed to import OK too. Even the "ti" ligature in Calibri-Light always came across in the import. I have not checked how those imported characters are coded. Are they just outlines with odd codes like in your original above? Or? Have to check. So the writing application has a definite effect on how well it works. The print to PDF with full font embeds brought over all ligatures on import to APub. Why do the Calibri-Light "ti" standard ligatures come over when yours did not? That can only be attributed to how the writing PDF application creates the PDF. I tested more things than just the above and now my brain is tired of this. Need a break.

Yes, it seems quite bizarre to me too. I am going to test and see what happens when the full font is embedded, not just a subset. I wonder if then the connection is made to the correct glyph in the correct font. The font sub-setting is definitely a problem so I wonder if the full font embedding fixes this issue. But this also assumes the application makes the proper connection to the embedded font, and I am not sure if APub can do this - there seem to be a number of issues with recognizing the fonts. If the PDF library used in APub does not allow/enable this it simply will never work. One of my PDF printers can force embed all fonts in the PDF (optionally). One of my PDF editors can actually install the fonts from the PDF (optionally). So I am going to test what happens with ligatures when the full font is embedded, and the reader/editor can use that full font. I want to know if it is possible with applications that have the right capabilities. Adobe applications will never embed the full font even if it is a free, open source, "installable" font. I assume this is their way of making sure all embedded fonts are basically broken. Since sub-setted fonts in those PDFs will never work properly for ligatures, any old ID PDF we try to import could (will) have problems if there are any ligatures. There are many other characters/glyphs in fonts which could also be a problem. So I think it would be helpful to determine exactly what is and is not possible on PDF import. And then document that to prevent users from wasting time figuring it out over and over again.

There are problems if Microsoft .NET framework is not up-to-date. It appears that .NET 4.7.2 is required as a minimum. You can download the most current version of .NET 4.7.2 here: https://dotnet.microsoft.com/download/dotnet-framework-runtime/net472 Install that and then see if APublisher starts and runs.

There must be something else going on here. I tested with Kis Antiqua Pro, Rhythmus Pro, and Bookmania. Had no problems with old style figures with any of them. Perhaps you could make a short video to show the Affinity guys what is happening.