Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

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

  1. OK, thanks for your quick reply. The fonts I showed in my sample aren't the only ones affected by this problem. What I don't quite understand is why only some of his fonts (I'm guessing about 20%) would have this issue whereas most work flawlessly with Affinity and with other applications. I would have thought he'd use the same engine for all his fonts, as the typographical rules apply to all fraktur typefaces, regardless of their outward appearance. I also don't understand why this problem doesn't occur when using Word 2016, which was why I thought it might have something to do with Affinity. Still, I accept that the only way to find out would be to examine the code used in the affected fonts, but since none of these are freeware, this would require Mr. Helzel's permission. Bottom line this means that I will simply have to avoid using the affected fonts for any longer project, at least until further notice.
  2. Big fan of Affinity software suite here! As a fly in the ointment, however, I have now discovered an irksome problem with its handling of certain Fraktur fonts. In addition to being well designed and historically accurate, Gerhard Helzel's opentype fraktur fonts (www.fraktur.biz) automatically provide the correct setting of ligatures as well as the long s, where the typographical rules require it in German. Helzel's fonts may thus pretty much be considered the aesthetic standard in this genre. The Affinity suite accurately sets the long s as well as other ligatures like [long-]st, fi, ff, fl, etc. It also generally correctly does not set ligatures where these do not belong (e.g., in words like "ausstellen" or "auffinden". Unfortunately, with some of Helzel's fonts, the ligature fl is incorrectly replaced with an "fi" — instead of setting "auflösen" (correct would in this case be no ligature), Affinity converts the fl into fi, i.e., it sets "auffiösen". It seems this problem is confined to the ligature fl alone, and curiously enough only with some of the Helzel fonts, with most of them Affinity correctly sets [f+l] in such words. As MS Word as well as another Windows app of mine always function properly with the affected fonts, I conclude it must be Affinity that contains a bug here. Manually intervening with zero-width spaces is possible, but is a highly cumbersome method to use in longer texts. The problem only affects about 20% of the Helzel fonts and even with these, Word gets it right and the false ligature apparently only appears in Affinity (see attached screenshots for how both applications set the word "auflösen" in a few sample Helzel fonts). Is there perhaps a quick fix to this problem (e.g., substituting "fl" for "fi" at the relevant place in the code, perhaps?) that could be included in the next upgrade?
  3. Hi again, I've prepared a sample document which I've uploaded both as an Affinity Publisher as well as a *.pdf-document which hopefully shows what I meant with ligatures becoming decomposed when paragraph alignment is justified last line left. This is in my world at least a new problem which I didn't have with the old AP Version 1.7.3. Grateful for any tips or corrective steps, if possible. If you need the Mars-Fraktur for any reason, the OpenType-version of it can be downloaded here for free: http://www.fraktur.biz/MarsFrakturOT-Normal.zip Sample of Incorrect Ligatures.pdf Sample of Incorrect Ligatures.afpub
  4. Hi everybody, since the last update ligatures in Affinity Publisher (Version, Windows 10) only work properly if text is not justified. If I set text as left-, center- or right-aligned, ligatures like ff or fi are set correctly, but if I then set that same text as justified (last line left, centered, or right) the previously correctly set ligatures disintegrate into individual letters. The problem seems to exist independently of my choice of typeface. Also relevant to this are the following points: A couple of days ago, my Windows 10 was updated to version 1909 (Build 18363.693), which also included an update of Microsoft.NET. I have many German blackletter (fraktur) fonts developed by Gerhard Helzel that set the frequently used long s automatically, where this is appropriate. In addition, I have many (free) blackletter/fraktur and antiqua fonts from Ligafaktur (www.ligafaktur.de), all in the LOV-version, that set the long s and other ligatures automatically where appropriate. All fonts (ordinary antiqua, Helzel, and Ligafaktur) use the correct ligatures in Microsoft Word 2016, regardless of the paragraph alignment is left-aligned or justified. Similarly, all fonts worked flawlessly in Affinity Publisher until the latest update (to Version All fonts (ordinary antiqua, Helzel, and Ligafaktur) work flawlessly in Affinity Publisher if texts are simply set as left-, center- or right-aligned. If texts are justified (last line left, center, or right), however, all ligatures are dissolved into their individual components. The Helzel fonts still set the long s, where this is appropriate, but all other ligatures are dissolved. With the Ligafaktur fonts, all ligatures are dissolved and a round s is erroneously substituted for the long s. From this I conclude that the ligature problem lies with the newest update to Affinity Publisher (to Version I'm not qualified to speculate as to whether or not the contemporaneous update of Microsoft.NET is likely to have something to do with it. If I set kerning to "manual" or optical alignment to "none", there is no change. Does anyone else have this issue? Does anyone know of a quick and simple fix to it? Many thanks in advance. Faneflycht
  5. The numbered list button in Publisher seems to work only if used at the top level and sequentially. If one tries to introduce a list entry hierarchically below the top level (e.g., "1. History ... a. 1960s"), a second listing number is introduced (i.e., "1. History ... a. a1960s"). If one tries to remove the extra "a", the list number disappears entirely and the entry is then converted to normal text, but as it seems with a different indentation than either the previous list or previous text. A workaround using text styles is possible, but cumbersome to use, and the numbering is then no longer automatic. A similar issue concerns footnotes and endnotes. One would wish a button to handle this. Currently, one must, it seems, use a text style as a workaround. One must then keep track of the numbering oneself. If one wants a footnote on the same page (rather than an endnote on a separate page), one has to insert a separate text frame so as to avoid having the footnote move if additional text in the main text frame is inserted. As there are very limited entries in the help section on these issues, I must assume that I haven't simply overlooked something obvious. If I'm wrong on this, I'd appreciate a hint from someone in the forum. If on the other hand my concerns are valid, I hope remedies will be offered in the next version, as both features seem to me fairly central in a professional DTP application like Publisher. Many thanks in advance, Fahneflycht
  6. In my view, the probably most serious missing feature in the current Publisher beta is that there is still no quick way to insert a footnote or an endnote. It would be desirable to have a tool for this, once Publisher goes commercial on June 19. Maybe it's no big deal -- Page Plus managed footnotes and endnotes very well. If such a tool is already being planned, it would be very nice if one could also insert cross references into footnotes/endnotes.
  7. AP will be a great application one day, but it still has a ways ahead. By way of the beta process, hopefully most of the missing (or still unclear how to use) features will be added and most of the bugs fixed. I am willing to be patient based on this prospect. In the latest beta version, the automatic ligature settings of Gerhard Helzel's Fraktur fonts work flawlessly, proof that progress is possible. Here's my quick and preliminary list of additional suggestions for future releases: 1. I, too have been using Page Plus for years. I think AP will prove more stable than PP, and I for one would accept forfeiting some of the user friendliness of PP in return for more versatility and stability. Even so, the ability to import PP and Word documents directly (i.e., without intermediate conversions) into AP would rank high on my wish list. 2. In AP beta, the color selection in text styles seems to behave somewhat erratically. I've formatted text in a particular color and the next day, it seems like some kind of default has substituted the color I had defined the day before, even though I had converted the base text style and saved my changes. Maybe I've just overlooked something or done it backwards, I don't know. A nice feature of PP was the ability to select predefined colors according to, e.g., the CMYK or RGB schemes and apply these to text with one click. Would be nice if one could save one's favorite colors and apply these with one click by way of a button or an icon and not have to adjust the individual settings each time. 3. The "base" character style uses Arial 12 pt. When I define a new group style with a different typeface and type size, AP seems correctly to save the corresponding settings for that group. When I then define a character style based on the new group style and apply this new style to existing text, however, I seem to end up with the correct type size, but in Arial. When I try to redefine the tracking setting of the character style, I end up with Arial and the original type size (12 pt). I have to admit, I'm still in a trial-and-error mode with this and have perhaps simply not yet figured out the correct way to do it. Someone who's ahead of me might wish to test to see if the problem described is just my own ineptitude or if it's a real bug that could perhaps be easily fixed. 4. I haven't detected yet how one can add footnotes or endnotes to AP documents, but maybe this is already in the works? Greetings, Fahneflycht
  8. Sorry to nag about an esoteric issue that is probably of no concern to the vast majority of DTP users -- to me, however, it is highly important that the automatic typesetting of long s in Gerhard Helzel's open type fonts function properly - which is still not the case with build (win). If the automatic long s-function can't be implemented in Apub for some reason, I would have to continue to use Word, where this function works flawlessly, even as Word is rather clumsy to use in so many other aspects of DTP. But if this particular function works so well with Word, why can't it be done in Apub? Would seem to me that a skillful programmer could solve this quickly. However, as I am no programmer myself, I may be making an inference that is way beyond the scope of my knowledge, so please pardon me if I'm mistaken in this regard.
  9. I frequently create documents set in the traditional German Fraktur alphabet, which requires certain ligatures that are not used in texts set with ordinary Roman letters. The most important one of these is the use of the so-called long s (Unicode U+0073), which may not be used interchangeably with the normal so-called round s but is used according to certain rules. The best Fraktur fonts out there are those that have been digitized by Gerhard Helzel (see http://www.fraktur.biz/). His OpenType fonts have been programmed to employ all required ligatures including the long vs. round s. These fonts work perfectly with Word for Windows 2010 and later and with InDesign as well as with XeLaTeX and certain other freeware programs. Most of them (not all) also work with QuarkXPress 2015. With the beta version of Affinity Publisher, the automatic setting of long vs. round s doesn't work, although conventional ligatures do seem to work. On my wish list would be that the above-mentioned OpenType ligature automatic would work also with Affinity Publisher.
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. 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.