kenmcd

Where did you get these "AT" fonts? News 701 BT, Stencil BT, and Zurich BT are old Bitstream ttf fonts. Not familiar with AT fonts. And what type of fonts are they? TrueType TTF or old Type 1 fonts? Can you provide the fonts?

That is why no Adopey application has ever been installed on this laptop. All the hidden folders and files. All the c**p buried in the registry. Most obnoxious was figuring out why un-installed applications and services kept re-appearing. They buried stuff in the Windows Task Scheduler to run tasks daily which downloaded and re-installed all this c**p. Even just installing Reader installed their copy protection service, other hidden junk, and the re-install tasks. Viruses are actually easier to get rid of. So this laptop has never had any Adopey stuff installed since it was new. I do think InDesign needs to be in the comparison for people considering switching. They need to know before hand what is going to be missing (avoid the shock). Adding a whole languages section - interface and output. Thanks for the comments/info above.

OK. Converted it to docx and text. The text file is going to be much easier. Really not much actual content there - easy to paste into a new table. Need to add line items for both the good and the bad. I have in my head a bunch of stuff related to fonts, OpenType, typography, etc. The pluses (e.g. support Character Variants), and minuses - missing features, bugs, etc. Including "annoyances." Including unique advantages. @cyberlizard The prices are a great idea - going right at the top. @BatteriesInc I know nothing about IOS and iPad. So any comparison line items you think appropriate to add would be great. APub advantages should be added. Work flow, personas ... ??? APub disadvantages should be added. InDesign advantages should be added. InDesign disadvantages should be added. QuarkXPress obviously added their advantages that they want to emphasize. QuarkXPress disadvantages should be added. The goal is a real, honest, user-oriented comparison for making an informed decision. Not just biased incomplete marketing fluff. Suggestions welcome.

What a terrible design of that document. Surprisingly bad. From a company that makes graphic design software. Nobody saw how bad this is? Looks like the "designer" knows the tools, but is clueless about basic design issues. Centering a scan list in a column - dumb. No reason for this to be landscape - really dumb. Loads of useless unnecessary white space between actual data - dumb. Like the content. It is obviously biased, but a good start. Missing important stuff (to me at least). Think I will redesign it, and add a bunch of stuff. And try to make it more objective.

Brilliant observation. Thanks for sharing.

This is actually kinda fun. It is like watching a train wreck. Just cannot look away. Reminds me of that old saying... something something blah blah blah ... "given enough time could type the entire Works of Shakespeare." Or something like that. Something similar could happen here. Everything you ever need to know to implement Indic support in Affinity applications. Of course all of us will be long gone long before that ever happens. Need a snack... this is gonna take awhile.

I do not understand. It is a monospace font, and it is being aligned to the character bounding box on both the left and the right. If it were a proportional font, there would be less side-bearing white space on the punctuation - so it would appear closer to the margin. Are you expecting an optical alignment or something? On a monospace font punctuation? Appears to be working as expected with that monospace font. Perhaps you need to change to a proportional font - which is more appropriate for running text. Note: if you want that mono look, but not with the issues like this, there are duo-space, tri-space, quad-space fonts - where the narrow glyphs like i l . , ! have a narrower character width. Still have the mono-look but flow better as running text.

Adobe also had ME versions created by a partner company before World-Ready Composer (WRC) was released. I guess as WRC got better over CS4 to CS5 to CS6 that eventually the ME editions were no longer viable.

This is the one I was thinking of: https://forum.affinity.serif.com/index.php?/topic/201566-all-affinity-products-failing-to-open-or-create-new-project-caused-by-a-font/#findComment-1194668

The Adobe World-Ready Composer made HarfBuzz the default shaping engine awhile ago (year+). Before that it was their own second shaping engine, and then HarfBuzz was an alternate. They basically have two text engines. The original text engine and then they added the World-Ready Composer in CS4 (and missing lot of stuff until CS5, and CS6). Many, many, many hours, and lots of money. Affinity has the same issue they had - you cannot simply just plug-in a new shaping engine (different APIs). It has got to be really expensive and time consuming to add another text engine (and a much more complicated one at that). Adding complex scripts affects a lot, but RTL adds even more. It affects everything not just some text blocks. User interface, multiple OpenType features, dictionaries, hyphenation, justification, table of contents, footnotes, end notes, comments, change history, styles, scripting, plug-ins, search, etc., etc. Everything. So I doubt they, Affinity, are going to just plug-in HarfBuzz. Adopey added another entire text engine. Have no idea how Affinity is going to address this all. They may add Indic support first as it will fit into LTR (would be my guess). But even that is a huge undertaking if they continue to write their own shaper. Dunno what they are gonna do. We can only guess. Side note: the other main current maintainer, and repo manager for HarfBuzz, Khalid Hosny, is Egyptian (IIRC he is a professor at a Cairo university). He is also the one who originally added HarfBuzz into LibreOffice to add OpenType support. And more recently added variable font support into LibreOffice. And multiple Arabic fonts he has made are available in Google Fonts. GF commissioned him to make a variable COLRv1 Arabic font as a sort of latest-font-technology demo. Someone here in the forum tried to use it in APub and APub choked on it.

No. It is not the problem. Which is my point. Clueless rants – by those who have no idea of what is actually required – get quite tiresome. Which is why I usually ignore them. But I am soooo sick of this "blah blah Unicode blah blah" nonsense. It just shows the writer has no clue.

Unicode support has nothing to do with this issue - so I wish people would quit saying that as it is incorrect and misleading. Unicode is fully supported.

libavif - Library for encoding and decoding .avif files https://github.com/AOMediaCodec/libavif Free open source - which is the whole point of AVIF (and AV1).

There are always conversion errors. Depends on the tool used, whether the Type1 was Mac or Windows version, unique hacks in the font due to the limited number of characters, etc. Almost always issues with the various quote characters. Check all those. Check for duplicates, and wrong glyphs in the wrong character (code point). Conversion by glyph number (GID) makes encoding assumptions which are often not followed in the font. Conversion by glyph name is usually better, depending on the tool used, but there may be duplicates and wrong names. Which results in wrong code points. So review all the characters and glyphs for errors. Will prevent surprises in the output. My offer still stands.

Use Justification Options, not kerning. There is an excellent free manual for Publisher here: https://forum.affinity.serif.com/index.php?/topic/191879-unofficial-pdf-manual-expert-guide-to-affinity-publisher/#comment-1124211 The Justification Options are on page 168 (in this version of the manual). Here is page 168:

Takes 5-10 minutes to convert it. Be happy to help. What font is it?

This is an ongoing bug. What is Affinity interpreting wrong in the IDML import that causes it to turn-On ordinals? There have been other issues posted with odd features enabled.

@713 I have a few questions after rummaging around in these fonts. First, I now see what they are doing with the stacked shapes. For closed shapes like the O or counters in b, d, e, etc., they duplicated the shape, stacked it on top, and then reversed the direction. So it gets rid of the fill because it looks like a normal counter. Fixed Eng VandLine 0, O, o, and Q like this. Also, almost all the contours which appear to be single lines - are not. They reverse back over themshelves to create a closed contour. But since the nodes are all in the same places, no fill appears. This is even done with the uppercase I and lowercase L (l) in Eng VandLine. That is why they work in Eng VandLine. In CNC Vector they are just a single line. So if I change the ones (I+l) in CNC Vector to be done the same way, they will work. I would like to fix these fonts and put them back out into the ether. Which brings me to my questions... CNC Vector - some weird stuff in there. I changed the vertical metrics to be more sensible. Added a .notdef symbol (required these days). It may make sense to change the I to have serifs, and the l to have a tail, or add the disambiguated forms in a stylistic set. Same with zero - add a slashed or dotted zero alternate. The spacing is really odd. Almost no left sidebearing (which means when you add a stoke it overlaps the margin), and the general spacing is just tight, and uneven bad. How do you deal with this? Does this make sense for your use? I assume you would have to adjust the tracking with just about any sizable stroke. And the diacritics (accents) are all too low, and different sizes. Add a stoke of any size and they touch. I know this depends on the size of the stroke, but the default seems to low. And they should have the same visual weight. (the tilde is huge) To test I can "expand contour" in FL. This is just 50 units: I know this depends on the diameter of the tool (your laser in this case), but these look too low (and mismatched visual weight). Please let me know your thoughts on this (improving this font). Eng VandLine looks pretty easy. Fix the fill errors. Add .notdef. i will look at the other 11 Eng fonts to see if they are worth converting

Yeah. When I looked at that one it just made no sense to me. I could not see how that was supposed to work. Odd lines - like across the bottom of the A. Duplicate shapes on top of each other. It just seems broken. Maybe I will mess with it a bit until it makes sense to me. And let you test it. Did not get to fixing CNC Vector today. I'll get to it tomorrow.

It is not the fonts. It is the dumb application creating the bad PDF. Text handling in PowerPoint is notoriously bad. The text engine is antiquated. There have been a few recent improvements, but it still sucks. The PDF writing application decides the encoding used, and if ToUnicode is included. Which in this case - it was not included. Affinity uses the ToUnicode info to import the text for editing. Since it is not there, no text appears. The encodong chosen can also depend on the characters used in the document. If there are multiple languages/scripts, the CID encoding may be appropriate. In this case PowerPoint simply did it wrong (really wrong, it is a mess). Calibri was encoded with WinAnsiEncoding - correctly. I put text for all three fonts into LibreOffice and Word 2024. ArialMT, Calibri, and Arimo-Regular. I entered the text below, highlighted each block of text, and applied the fonts. ArialMT ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 1234567890!,."#$%&'() Calibri ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 1234567890!,."#$%&'() Arimo-Regular ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 1234567890!,."#$%&'() Then Exported to PDF from LibreOffice and Word 2024. LibreOffice chose to encode all of them as Built In. Word 2024 chose to encode all of them as WinAnsiEncoding. If you did this in a macOS app such as TextEdit or Pages, it would probably encode it as MacRoman. Becuse of the limited characters used. CID Identity-H encoding is not needed for this text, but it could be used. Some apps are lazy (or smart?) and encode everything as CID Identity-H. If the text was different, it may require CID Identity-H, because WinAnsiEncoding and MacRoman then do not cover all the characters. Sometimes adding one character, can change the encoding used. Below are the test PDFs. Both PDFs allow copying the text. Both PDFs open in APub and are editable text. Try them yourself. Export-to-PDF-from-LibreOffice.pdf Export-to-PDF-from-Word-2024.pdf It is not the fonts. It is the lame application which created the PDF. Side note: why would anyone use PowerPoint to create crossword puzzles? That had to be painful. UPDATE... @big smile Do you have access to the original PowerPoint files? Because those could be opened in LibreOffice Impress, and exported to PDF again. And that may work a lot better. Or not.

As suspected, Lora only has 1-4 in the basic Unicode superscript characters. The test string is in the upper field, and the lower text is Lora. Test string: sups u ⁰¹²³⁴⁵⁶⁷⁸⁹⁺⁻⁼⁽⁾ⁿ

That may be fixable in the font. Those are both just straight lines with nodes at the ends. And IIRC there is a bug with this (I can find the post later). There is a work-around - add another node on the line - and then it will appear. Later today I will do this in the font (add another node to those characters) and see if that prevents the issue. Will post the modified font here later. Do any of the other fonts work?

It looks like the OpenType Superscript feature is On. What font are you using? Many older fonts only have Unicode superscript characters 1 thru 4. So the 5 thru 0 are not available - and are going to be normal size. Check the Typography panel for the style used.

There is a lot of those fonts around (for CNC, Cricut, etc.) for free. These two are quite common: CNC_Vector.ttf CNC_Tiny_Tricks.ttf I expect both of these to work. These two are structured a little different - please test to see if they work. This is one supposed to work in CNC, but some of the a shapes do not make sense. MecSoft_Font-1.ttf This one is a conversion from an old Type 1 font (1 of 12). If it works it may make sense to convert the rest of them. Eng_VandLine.ttf You should test all characters. There have been some issues with single straight lines (like an uppercase I, etc.).

That is kinda the opposite of my wild guess, but glad you got it working.