Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by Lagarto

  1. Mostly true for me, too, especially as recently used or document fonts get grouped for quick access anyway so once the font candidates for the project have been picked, there is no need for scrolling through the font lists. The netfonts change the game to some extent especially with features that look for similarity in fonts (accessible e.g. via Adobe Fonts but not activated). In this context it is convenient to to see in one view the available styles and font's capabilities, similarly as on a font web site or when browsing through a printed fontbook.
  2. Next version then, hopefully. And preferrably as expandable/collapsible sublists as they are easier to control.
  3. Yes, like this: Not too useful unless implemented so that the family list itself can be scrolled fast (e.g., VivaDesigner way only works ok with a keyboard and is not practical if several hundreds of fonts are installed). But InDesign CC (2018=>), Affinity Publisher, and CorelDRAW are good examples of usefulness of this feature, especially when combined with filters.
  4. Ok, good to know, a very welcome change. Does it now also show font families and actual fonts in the same list?
  5. I had a look on some page layout apps and the way they list fonts (there are additional features like favorites, font similarity, availability etc., that make the font lists more and more advanced and complex but here basically only the typographical aspects are considered): Microsoft Publisher 2016: Does not support advanced OpenType font family grouping, but only Windows menu name style based grouping; allows random Bold, Italic and Bold Italic for any font (aka faux formatting). Listed here first as this is the way most non-graphic Windows applications list the fonts. This is also typographically the worst method of listing fonts. As for the rest, the apps are presented from best to worst, strictly typographically considered. This is of course much just a personal opinion, and also highly version-dependent so more recent versions of apps may have improvements that would change the order. And Scribus aside, the differences are not big btween the applications: 1) CorelDRAW 2017: Supports advanced OpenType font family grouping and Windows menu name style based grouping; does not allow faux styles. Shows font technology. Can filter preview lists “as you go” by user-selectable choices in many useful ways, inline slider for font preview size. 2) InDesign (CS6/CC): Supports advanced OpenType font family grouping but in addition has grouping capabilities beyond other applications that allows listing of older types without equivalent metadata under typographically correct font families, and using correct style names (e.g. Oblique instead of Italic, etc.). Does not allow faux styles, but allows style button (and shortcut) based formatting using correct style mappings when the font is truly available. Groups fonts by writing system. 3) VivaDesigner (9.5): Supports advanced OpenType font family grouping but in addition has some advanced grouping capabilities that allow listing of older types without proper metadata under typographically correct font families. Does not allow faux styles, but does not either support mapping shortcuts or buttons to quickly apply formatting for selected text. Shows font technology and groups fonts by writing system. NOTE: Cannot show font previews, but this is not considered important in this context as small previews are generally pretty useless. Complete font lists grouped by family are also useful only with a relatively small amount of installed fonts. 4) Affinity Publisher: Supports advanced OpenType font family grouping, and Windows menu name style based grouping; does not allow faux styles but allows style button (and shortcut) based formatting using correct style mappings when the font is truly available. Does not show font technology and does not group fonts by writing system. 5) QuarkXPress 2018: Supports advanced OpenType font family grouping and Windows menu name style based grouping; allows faux styles with styling buttons, menu commands and shortcuts (but not as listed faux font names). Shows font technology. Groups fonts by writing system. Cannot show font previews per family in one list. Allowing careless faux formatting is a big minus but at least this is not extended to actual font lists, but that is the reason (in addition to allowing font family and member listing and previews only as two separate lists) is why QXP has been placed here below Affinity Publisher. 6) Scribus: Does not support advanced OpenType font family grouping nor Windows menu name style based grouping; does not allow faux formatting. Each available font is simply listed separately. It is obvious that none of the mentioned apps show any problems with listing or accessing the fonts installed on the system. While it should probably be noted that many of the about 700 fonts installed on the test system proceed from major font providers (Adobe, Monotype, Linotype, Bitstream, etc.), and from known, typographically high-standard font foundries, there are also dozens of faceless stock fonts that have been installed with diverse popular software, and no font manager is used on the system to do any kind of house cleaning.
  6. Please add full set of fields in the context menu (mouse right click) so that it becomes easier to add e.g. Section name in the header on a master page. Or, at least make them available under Text > Insert > Field. Now most fields must be picked from the separate Field panel, but at least the Section name would be convenient to be available from a menu, similarly as the Page Number field.
  7. It is difficult to try to resolve your problem without knowing the complete list (with font related metadata) of your installed fonts (and also ones that possibly get activated at request, like online fonts). It may be that it is just a small subset of fonts that break the Affinity-driven enumeration of fonts, or are you saying that the whole list is somehow corrupt? It is also unclear what the actual consequences of your problem are: 1) Are the lists just messy (that is, specific fonts are hard to select from the user interface because font family context is lost), but your font selections in Affinity apps still result in correct font to be chosen and also exported in PDF (i.e., for production)? Or do you also get unexpected font errors in production files? 2) Are certain fonts missing from the Affinity lists? I have myself about 700 fonts installed on my laptop where I have Affinity apps installed and have not experienced font related problems, and it does not seem based on this forum that font related problems are very common with Affinity apps. Yet it is clear that they do enumerate fonts differently than e.g. InDesign, and to some extent QuarkXPress. All these applications try to enumerate the fonts meaningfully in families and also try to support different technologies and the ways OpenType, TrueType and Type 1 fonts use font meta data to group fonts. All these apps also try to list (and at least differentiate) genuinely available fonts and do not randomly allow using Bold, Italic and Bold Italic styling just with any fonts (similarly as e.g. Microsoft Word allows). But sometimes there can arise conflicts which are hard to overcome. Just an example: Years ago I had to use a font utility to be able to get plain Helvetica Medium, Medium Obligue, Bold, and Bold Oblique fonts from Adobe FontFolio 9 (Adobe Type 1 fonts) listed in Adobe environment (InDesign, Photoshop etc.) at all, because I had a font with the family name Helvetica already installed on my system. I do no longer remember where the conflicting fonts came from and why I did not simply remove them to be able to use the Adobe version (similarly as I did with Symbol, which was a TrueType from Microsoft, while I wanted to use Symbol the Adobe Type 1 version from Adobe), but it was related to ensuring that fonts used in older projects are available also in the future, so it was basically a machine specific problem. Anyway, the only way I could get these most basic fonts of all listed in Adobe environment (on this particular computer) was to use a utility and change the so called Windows menu name (kept in .PFM files, while the actual font is saved in .PFB files), and change it to Helvetica AT1. All other applications could list both Helvetica versions without renaming but not Adobe. I still have these fonts installed on my laptop and they show as follows in InDesign, QuarkXPress and Affinity Publisher: InDesign: QuarkXPress 2018: Affinity Publisher: QuarkXPress and Affinity Publisher seem to behave similarly at least in this particular case, while InDesign clearly uses more advanced family grouping, information of which is not available in the .PFB files, nor in the .PFM files. Here is the actual meta data that is saved in the .PFB files, as shown by TransType 4: As can be seen, the font name used by Adobe environment (Helvetica Medium) is not saved as metadata in font itself. But Adobe clearly "knows better". What is interesting is that FontLab Studio VI and TransType4 fail to list these fonts as installed fonts, at all, they completely ignore Windows menu names from .PFM files, while all other applications on my system correctly enumerate them as istalled fonts. Anyway, my point is that InDesign uses advanced font grouping (based on non-standard meta data and their custom font enumeration methods) which results in these four AT1 Helvetica fonts being cleverly and typographically correctly grouped under the common Helvetica family name, that includes the following fonts: ...while QuarkXPress and Affinity Publisher cannot group these fonts under Helvetica family name but show its four menu styles under the Windows menu name "Helvetica AT1" which I have given for them. But without this trick, Adobe environment failed to originally list the font at all, at the time I had to do the renaming trick and had a conflicting Helvetica fonts installed on my system. At the moment I no longer have that other Helvetica installed on my system but the old four Helvetica Type 1 fonts still seem to work flawlessly on every application that I have installed on this computer. I hope that this shows that fonts can be tricky even if they are by no means corrupt. The problems are often machine specific, and the easy advise is to get rid of conflicting fonts. But always this is not possible, and then I guess the advise is that you just have to "git gud". Affinity can certainly improve the way the fonts are enumerated and grouped in their apps. E.g., fonts could be listed by font technology (AT1, TT and possibly OpenType PS and TT separately, as well as variable fonts and online fonts, if possible), which might also help in grouping them correctly and avoiding directly conflicting menu names (as there are other grouping criteria that helps so avoid name breaking). But there may simply arise name conflicts which are impossible to resolve. If FontLab Studio VI and TransType4 cannot list certain AT1 type fonts as installed (while all other applications installed on the system can), I would not insist that a graphic design app should be able to resolve complex name conflicts on each and every system. But it, too, can get better, even if never "gud". Something has to be left for professional users, as well. UPDATE: TransType4 and FontLab Studio VI seem to actually completely ignore installed Type 1 fonts -- which in many ways are obsolete even if fully operating fonts, so this is a separate matter. But the example is still valid, as it illustrates how apps need to build meaningful font lists partly on their own (using available meta data and trying to group fonts correctly), but when name conflicts arise, they can fail to list the font altogether, or fail to place it in correct family group. Using a font manager would allow selective usage of fonts so that you only activate ones needed for specific projects, or at least keep the conflicting fonts apart and use them app-wise only when needed. If this does not help, you need to edit meta data (or Windows menu names, if you have still Type 1 fonts on your system).
  8. I see. I have used very little CorelDRAW's multipage features (other than for some n-up layouts). But it is still a great tool for vector drawing and a good Swiss army knife for importing and exporting all kinds of stuff, creating SVG for web, etc. Its scriptable object model is also awesome.
  9. You can use section name fields on your master pages to fetch automatic header text from sections (see attached). This works similarly as in InDesign. So you do not need mutliple masters just for different sections. Also, you can suppress master page text similarly as in Quark and InDesign by using master layer detach editing. headers.afpub
  10. Yes, it requires using something else than Microsoft PDF creator. E.g., using Adobe PDF creator as the printer driver allows you to force gray output (RGB black becomes grayscale black), but it becomes tricky if you also have other initially RGB based content like photos, charts, etc. (complete conversion to CMYK and to specific color profile is easy to do but then text black normally also converts into 4-color black, which is not wanted). In a way it has become much simpler, but there are always new things to learn, the whole business has changed more or less completely at least twice during the time I have been active.
  11. OMG, aren't Advantage subscribers happy that they get bug fixes four times a year But seriously, isn't there backwards compatible .qxp file format in QXP2019 (equivalent to File > Save As / Downsave)? It seems IDML is becoming a universal standard for exchanging DTP data (even if Affinity does very well opening multipage PDFs) -- Scribus does it, VivaDesigner does, Quark does, and soon probably Affinity Publisher does. Good for everyone.
  12. One further note on this error: Perhaps the error occurs because the update routine does not completely wipe out the contents of the existing TOC text frame but assumes the frame to only contain code-generated TOC entries? Shouldn't it do it, rather than leaving manually entered text in the frame, and appending the TOC entries found by code? (And do this first of all to avoid massive TOC blunders, considering a possibility that it is assumed that TOC update really updates the TOC while it might actually update only the true TOC entries that are left hidden in the TOC text frame following the manually entered text!) Or, perhaps the feature could behave similarly as InDesign that asks whether an existing TOC (with the same name) should be replaced, and if this is allowed, the routine fully replaces the content of the existing TOC text frame so that whatever it contains, manually entered or as per code, will be deleted. If the user does not want to replace the TOC, the updated TOC content is loaded in the text cursor so that the user can place the contained text on a page or pasteboard in a new TOC text frame, and the old TOC loses its TOC status and becomes just a regular text frame.
  13. It seems to be specifically related to the TOC on page 2 containing unflown entries. If the text frame containing the TOC is opened fully, the error does not occur. On the other hand, if TOC panel is opened, it can be seen that the TOC on page 2, when selected, does not actually acivate the TOC1. If TOC1 is selected from the list, and updated, program immediately crashes. It also crashes if "Update all TOC" is clicked. The problem seems to be related to the TOC not actually finding any TOC entries based on the paragraph styles checked for scanning (all its entries have been created manually), and trying to place text "No table of contents entries found" in a text frame that is not big enough to fit it in. Once that text frame is fully opened, the text fits in, and updating the TOC no longer crashes the app.
  14. Thanks, thought it needs to be turned on somehow -- very useful in tracing PDF creation errors.
  15. I am not sure if I understand, or why this is needed, but if you are talking about auto-flowing text that is overflowing, you can do this in Affinity Publisher by Shift-clicking the overflow icon (at the lower right of the text frame).This works also with a text frame placed on a single page (you do not need to have a text frame on master page). Pages are added as required at the end of the document to fit all text so there is no need to extend the document page by page, or spread by spread. Removing frames (and adding pages as pairs at the end of the document when needed, to fit in unflown text) is another way you can force a blank page without inserting or removing pages, simply adjusting the height of the last text frame of the previous chapter, and removing the text frame from the page that you wish to leave empty. As you won't add or remove single pages, the text frames need no repositioning. But I think it is better to control the flow with breaks in a paragraph styles since this way the correct structure is retained even if you add or remove text or images at some point.
  16. I spent another moment with an 800-page .afpub version of a mirrored text-only document where a paragraph style causes breaks to next odd (recto) page, and it was actually not too bad (at least you won't be forced to manually reposition your text frames). There is clear sluggishness in most operations but it's all relative -- you mention that you have produced something like this with CorelDRAW. Moving up to Affinity Publisher after such an experience should feel like heaven!
  17. It is explained in the OP's description, but here goes: when you insert (or delete) a single page in a facing pages document with mirrorred margins, and margins on the left and right are not equal, you'd expect the application to automatically adjust the positions of text frames after the change. As it is now, the text frames retain their existing offsets so the left pages after the inserted or deleted page have the margins of the right page (master) and the right pages the margins of the left page (master). In InDesign, QuarkXPress and VivaDesigner you get the text frames automatically adjusted after such change.
  18. When a hyperlink's type is URL, the Go to Target button is not available (i.e., it is grayed out). This might be a feature rather than a bug, but I ended up reporting it here because the documentation does not mention anything about hyperlink type restrictions when describing this feature, and because one might expect the URLs to be visitable similarly as in InDesign, as it is often important to check that links (also URL ones) included in a publication are not broken.
  19. Thanks. It would be a useful improvement (and quite easy to implement, too). While URLs are by no means expected to be eternally unbroken, they are still typically meant to be active and working at publishing time (since why else even encode them as explicit hyperlinks in the layout). Also, URL hyperlnks do not always appear as URLs in the user interface, or are not necessarily even wanted to stand out visually (other than by changing the text cursor while hovering on top of the text) so it would be a tedious task to check URLs from the produced PDF.
  20. Quite odd. As mentioned I managed to create an isolated (non-reproducible) bug resulting in TOC page becoming rasterized on PDF export, by creating a URL hyperlink in one the "Heading 1" styled headings, and additionally the URL itself was not rendered as a hyperlink in the PDF. But I have not managed to produce an error where TOC page links do not work (I have been testing this with a document with 4 TOC levels producing a two-page TOC). You mentioned about pdflib.log -- I tried to look for it but could not find. Where is it created, or do I need to turn on logging somewhere?
  21. Could you include the exact regex search clauses as a reference (for someone knowing the exact syntax used in Publisher). I am totally clueless myself in use of regex but it would be very useful to verify the correct syntax, and secondly, take care that even if wrong syntax is used, it would not result in these kinds of errors (program crashes, and as you mentioned, more serious errors where incorrect replacements are done silently).
  22. I tried to drop in the dummytext.rtf (or its .doc version) (about 800 pages of "lorem ipsum" body text) using mirrored facing pages layout using diverse page layout applications, and found the following: 1) InDesign: no problems whatsoever, imported the file in about 15 seconds, after which you can immediately browse through the document in a flash; the app behaves basically the same as if you had a 10-page document. Complete flow control and support for page insertion and verso/recto adjustment. 2) QuarkXPress 2018: much the same as InDesign, but there is some sluggishness in browsing through the document immediately after import; but as far as I can tell there is no support for text flow based paragraph styling (and you need to use soft keyboard simply to add a page/column break if you have a laptop without a num pad Enter key), which may be a nuisance if you have much breaks in layout (which you typically would not have e.g. in a novel). Support for verso/recto adjustment. 3) Affinity Publisher: can do the job but there is much sluggishness. No verso/recto adjustment, but there is InDesign-like flow control, and if you can break the book in separate chapters, you can do the job with Publisher. 4) CorelDRAW 2017: churned the text for a while, but managed to import it, but flowing the text to a 800-page publication would be utterly painful experience, based on an effort of trying to flow the text to just a couple of more spreads... 5) Microsoft Publisher 2016: Stopped responding, and I stopped trying after 15 minutes without any noticeable advancement (assuming that the program had crashed). UPDATE: Microsoft Publisher supports flow control in paragraph attributes (break to next text box) and accordingly also in styles, but does not support automatic verso/recto adjustment -- but it warns that insertion of single page messes up the margins. 6) Scribus: crashes in stack overflow error after about 1 minute (but can import the file in non-autotext frame and then smoothly flow the text one spread at a time so it MIGHT be able to handle this if the text is split into multiple stories, as the memory overflow indicates a problem with sheer amount of characters in the same story). UPDATE: No flow control (other than manual frame and column breaks), and no support for verso/recto adjustment. 7) Microsoft Word would actually handle this kind of publication effortlessly, and supports mirrored margins (even if it cannot show correctly facing pages during editing unless a blank dummy page is added in front). But with proper PDF library you'd get perfectly acceptable K100 output. Bleeds etc. would of course cause some extra trouble but these are not typically needed in e.g. novel publishing. 8) Xara Designer crashed almost immediately on import (and it seems would not support mirrored margins anyway). 9) Viva Designer: imports the text without crashing but then text editing becomes sluggish. It seems that there is no support for style based text flow control but supports insertion of pages with automatic verso/recto adjustment. Then there is Serif's PagePlus which I have no experience of but as far as I know it is no longer developed, but could possibly handle this kind of publication. It is actually surprising that such a seemingly simple job as creating an 800-page mirrored text-only publication could be such an overwhelming task for this many applications claiming to be page-layout apps. This admittedly quite superficial test round showed that only InDesign, Quark and Word can handle the sheer amount of text effortlessly and could produce an acceptable print-ready document (Word with some restrictions, of course). Affinity Publisher could handle the job in parts without struggle, but is still way behind of InDesign and Quark, Viva Designer struggles a bit but can handle the job as one document.but pricewise is nearly in the same class with InDesign and Quark that both handle the task much better.
  23. There are methods of combining PDFs without causing any tampering of data but I understand if you do not want to perform this with a 3rd party utility but want to ensure integrity of print files. I am afraid that Affinity Publisher is not capable of handling well long documents, but it may of course be that the sluggishness that I experienced when trying this with a 800-page document consisting of mere text ("lorem ipsum" placeholder text from InDesign, which I included as a zip attachment above) was somehow affected by the nature of the text (it being just latin body text without any chapter breaks, etc. though I doubt this could have any effect on the matter, especially as I had turned off spell checking and hyphenation). Therefore I suppose that splitting the book into separate documents is the only choice if you want to use Affinity Publisher (at its current state) for book publishing.
  24. It does not seem to have effect on the matter. Not at least in the sample document with mirrored facing pages that I had attached. InDesign, Quark etc. have a feature called layout adjustment, which basically handles these kinds of repositioning needs, but inserting a page in a facing pages layout and ability to auto-adjust frame positions (related to margins) when the side of a text frame changes from verso to recto or vice versa is something that is handled automatically separately from the layout adjustment settings. I think that both features are missing from Publisher at this point, but I might be wrong, as I am only learning its use.
  25. I am not sure if I follow but basically you should be able to modify/exclude/add any element on a single page to which any master page is applied by "detach editing" it. That is, go to Layers panel, select the Master layer for that page, right click and choose Edit detached. Remove e.g. page number, edit or add any object, then click Finished. Changes affect only the master layer on that page.

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.