Jump to content


  • Content count

  • Joined

  • Last visited

1 Follower

About LibreTraining

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. LibreTraining

    ligatures for Whitman font don't work

    OK. I will PM you a link to a 7z with two fonts in it. Apparently the "LF" fonts are an older version (2003). It appears the TTF font is an actual old TrueType font, not an OpenType TTF font. The 2016 version I have is an OpenType OTF file (PostScript outlines). So I will send both the TTF and the OTF. Please test both and let us know how it works. My guess is the old Type1 font ligatures is the issue.
  2. LibreTraining

    ligatures for Whitman font don't work

    @raphaelmatto The PDF shows your Whitman font is Type 1. Perhaps APub is having an issue with this type of old ligatures. @Hangman Your PDF shows your Whitman font is True Type (CID). Assuming this is probably an OpenType TTF font. Perhaps it would be good to have raphaelmatto test with this font. @raphaelmatto I have the OpenType OTF version of this font. If you want to test I can PM it to you.
  3. LibreTraining

    Line spacing strange behaviour

    QuickTime does not play FLV containers. Plays fine in VLC Media Player. It is a bit odd to have AVC/AAC streams in an FLV container. I copied the streams into an MP4 container. 2019-10-11 16-12-07.mp4
  4. LibreTraining

    A random "glyph" problem?

    I think the odd way this font is constructed is confusing APub. The ff ligature is one of those few ligatures which have an actual Unicode code point (FB00). Fonts will usually use these standard code points as applications like LibreOffice will auto-correct the two consecutive f characters to this Unicode ligature. But in Roboto-Regular.ttf (v2.137, 2017) this glyph (#437) has no Unicode code point assigned. The glyph does not appear in the OpenType standard ligatures (as it usually would). The glyph is only accessible as an OpenType discretionary ligature (named f_f). I am not sure how it is even appearing if you have not enabled discretionary ligatures. This appears to be another example of Google Fonts weirdness.
  5. Were these fonts actually purchased separately or as a part of the monthly subscription? A subscription which is now ended? Note: Proxima Nova works fine for me on APub 1.7.3 Win. (both OpenType OTF and OpenType TTF)
  6. Dear Font Police, The San Francisco fonts are freely available for download from the Apple developer site. Anyone with the proper tools can modify the fonts, and they do everyday. A popular fonts sharing social media group has had a full family version of the San Francisco fonts available for quite some time which has been fixed to work properly on Windows by fixing the Apple names sabotage. I am sure they have only been downloaded a few hundreds, or thousands, of times. For development purposes only, for sure. Perhaps some font policing skills are needed there. Good thing Apple has self-appointed holier-than-tho font police to protect their meager fortunes from attack by unscrupulous operators seeking to understand and deal with development and editing issues related to PDF import of an OpenType raised colon. I am sure Apple will be sending their thanks soon for protecting them from this evil affront. <roll-eyes> Why is it every development forum has at least one font police protector-of-the-license? No font creator with more than half a brain is going to give a rats ass about people using their fonts to try and figure-out issues in an up-and-coming graphic design application. They would have to be a complete moron.
  7. OpenType fonts with TrueType outlines rather than OpenType fonts with PostScript outlines. If you do need the Display font I would be happy to help get it working. Apple sabotaged these fonts in a couple ways. - the name fields are configured to prevent them working properly on Windows apps - there is a deliberately incorrect checksum in the fonts which may cause problems I figured the way I fixed and converted these fonts would circumvent those traps. It does bother me that the Display font has an issue (a challenge!). Again, if you do need the Display font I would be happy to help get it working. Glad to hear it solved part of your problems.
  8. I did realize this morning an error in my thinking. When I print to PDF to force embed the whole font it is the PDF printer rendering engine that is doing the glyph/Unicode mapping, not the APub PDF rendering engine. So one of the many non-Adobe PDF printers may work correctly (as a work-around for now). Have to test some others.
  9. Could you please describe some specific issues with some specific fonts. So someone can replicate what you are concerned about.
  10. LibreTraining

    Superscript and Subscript not working

    Could you please be specific about which fonts you are required to use. Perhaps it would be useful to review the actual subscript/superscript features of those fonts. And also scientific inferiors, ordinals, tabular figures, etc. I am already working on this for another project and many of the fonts may be the same ones.
  11. Thanks for the ID PDF. These PDFs kinda confirmed what I was thinking based on reviewing the actual ToUnicode tables in the PDFs. When APub exports a font subset it does not put the correct glyph number in the ToUnicode table. It appears to just have increasing/incrementing numbers in that field. That is why we see glyph numbers like #03 which is just wrong. And the character it gets mapped to is also wrong where it is often simply [20] which is the Unicode space code point. When APub prints to a PDF printer and embeds the entire font it does a bit better. I saw in the ToUnicode table that there were now what looked like actual glyph numbers. It does actually have the correct glyph number for the "ti" ligature (#415), but it still does not connect that to correct Unicode code points. In my test PDF with the full font embedded it maps to: LATIN CAPITAL LETTER O WITH MIDDLE TILDE [19F] - which is obviously wrong. In your ID PDF, which only has a subset embedded, it correctly identifies it as glyph #415 in the font, and maps it to two Unicode code points: LATIN SMALL LETTER T [74] + LATIN SMALL LETTER I [74] - (Note this could be an error in my PDF tool as small letter i is actually [69] - or ID messed-up). The small letter t is correct as [74]. So it has the correct glyph number if you have the font installed. And it maps to the correct multiple Unicode code points if not. The "fi" ligature is different in that it actually has a Unicode code point. In your ligatures_apub2 PDF APub incorrectly sets the glyph number as 11 (should be #302), but it does map it to the correct Unicode code point: LATIN SMALL LIGATURE FI [FB01]. So APub is inserting both wrong glyph numbers, and wrong Unicode code points. Sometimes it does get one or the other correct, but not at the same time. Since we have not heard from any Affinity folks about this I assume that they know this is not working properly and currently have the fire hose aimed elsewhere.
  12. LibreTraining

    Japanese fonts list almost freezes

    Could you provide a list of the fonts, or the fonts themselves? Are these primarily commercial fonts, or free fonts, or both? I have seen some popular free Chinese fonts which would not work properly in APub (or many other apps). So I am wondering if some of these are also free fonts with similar problems.
  13. LibreTraining

    Publisher unable to group fonts properly

    Adobe has an additional 20 years of dealing with clueless users who install a bunch of crap broken fonts and then complain that the application is not displaying them properly, or printing is messed-up, or the export to PDF looks wrong. So in some cases they can guess what should be in the fonts based on partial information. Sometimes this works, sometimes it does not work. Just because you see some font listed does not mean they are all there, or that the export to PDF will work properly. The only way to really know is to create a test page with all the fonts in the family on it, and then check the screen output, the print output, and all embedded fonts in the PDF. Then you can say the fonts are working 100%. This "as ALL the competitors do" statement is complete nonsense. Below is an image posted in a font forum 10 days ago showing the font list in Adobe Photoshop. The user is asking for help because the fonts are not listed properly. Note the four darkest Sample previews in the middle that look all the same. What is listed as four fonts which all look the same is actually four different font families which each contain five fonts, for a total of 20 fonts in four families. Photoshop is displaying 20 fonts in four families -- as four fonts that all look the same. Crap broken fonts that Adobe cannot display properly. Does this look familiar to you? Kinda like your Helvetica mess. I fixed the fonts, tested in APub and LibreOffice, and sent them back. He was quite appreciative. I have yet to see any well-made non-broken fonts which do not group/list properly in APub. You install a bunch of crap broken fonts and are still trying to blame it all on APub/Affinity. If you want to blame someone, look in the mirror.
  14. I sent you the test fonts via PM. The Display-Bold and the Text-Regular like in your original PDF. The fonts have been converted to OpenType-TrueType which can be embedded fully. Your original PDF only includes a subset of the fonts. Embedding the full font may work. As I mentioned above I have a PDF printer for Windows which allows me to force embed the entire font. So if you could find something similar for Mac that may help. Be interested to see what happens.
  15. @stutes Would you like to test a font which appears to be working? APub seems to do better with glyphs from OpenType features when the full font is embedded. So I converted SF to OpenType with TrueType outlines and tested. I put some of your dates text into LibreOffice and created two PDFs. - Export to PDF - which embeds a font subset - Printed to a PDF printer which allows me to force embed the entire font(s). I expected the subset to not work, and the full embed to work. Surprisingly it all worked in APub. Both Placed PDFs appeared correctly (meaning the right glyph appeared). Opening both PDFs in APub also worked correctly (meaning the right glyph appeared). I would be interested in seeing your results with the same font.

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.