Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by Lagarto

  1. Thanks for the explanations. Did I understand correctly that the safe method to encode ligatures is using the "concatenation" method, e.g. (U+0066+0069) for the ligature "fi", and (U+0074+0069) for the ligature "ti", rather than referring the existing code point for the glyph itself, "fi" (FB01), or "ti" (whereever that is placed in the font, whether subsetted or not)? Anyway, it was good to see that PDF-XChange (Editor Plus) can actually edit the text as if in text editor no matter how the ligatures are encoded, that is I can copy paste the actual Affinity Publisher created "ti" ligatures without problems, while I cannot do this in Adobe Acrobat (or any other tool, as when the PDF is opened, the "ti" won't be rendered, even in Affinity Publisher, and copy pasting from one app to another is guaranteed to fail when custom encoding is used). I had to purchase this tool recently because InDesign could not produce an acceptable PDF/A archive format for a thesis (!). I have now used the tool to automatically generate hierarchical bookmarks from a TOC (quite useful with Affinity Publisher), so it has proven to be quite a capable PDF tool!
  2. Actually it could also be so that Affinity Publisher specifically uses the actual ligature codepoints, while InDesign uses ligature attributes, and just "ti" and "tt" as single characters. So whether a ligature is shown or not, depends on the viewer (i.e., if hardcoded glyph, all viewers can show it, if an attribute, the viewer must support the ligature as a feature), and whether a ligature codepoint is used as a glyph or not, when copy pasted, depends on the destination software (i.e., whether the destination software decomposes the hardcoded glyph as separate characters, or supports use of hardcoded ligature glyph itself not as an attribute but glyph). See below how PDF-XChange can edit and copy the selected ligature in the PDF created with Affinity Publisher ("ti" as a hard-coded glyph), which PDF-XChange can copy paste to duplicate it: ...and below editing the PDF created by InDesign, where "t" and "i" are separate glyphs which are rendered as ligature glyph "ti" because it has been coded as formatting attribute: Just guessing. I do not know internals of PDF encoding, but this kind of makes sense. EDIT: More guessing... The "attribute" status seems to be achieved by encoding the composing character codes to follow each other, e.g. "t" + "i", which the rendering application maps to the actual ligature glyph, if it supports the feature, and the font has the corresponding iigature glyph; and as separate glyphs "t" and "i", if it there is no support. Affinity Publisher seems to refer directly the ligature glyph code, so that when it is copy pasted it does not necessarily get correctly rendered in the destination app. See below ligatures_apub2.pdf, which has ligature "fi" added in the text. When this text is copy pasted back to Affinity Publisher (or Illustrator, or InDesign, etc), the "fi" ligature will be correctly rendered (either as ligature "fi" or separate "f" and "i", depdending on whether standard ligature atttibute is turned on in the destination app), but not "ti" (which is not supported in most fonts, but will not be rendered even if Calibri font, that supports it, is retained in the destination app). Don't know whether it is a question of these two ligatures having been encoded differently, or whether both are "hard coded" (referring directly the ligature glyphs), and only "fi" gets mapped to ligature "attribute" by encoding it as "f" + "i" (U+0066+0069). Anyway, concatenating the composing characters seems to be the safer method, as it is not dependent on the font's capabilities, or the rendeing application's ability to use ligature glyphs.. ligatures_apub2.pdf
  3. Here's one created in InDesign and Affinity Publisher. I think it is as MikeW mentioned above, Affinity does not use the font's codepoint for the ligature but just uses an unused Unicode codepoint, which shows when you copy paste the text. If you copy paste the text from PDF created by InDesign, you get those characters decomposed (so that the destination software defines whether a ligure is used or not). ligatures_id.pdf ligatures_apub.pdf
  4. I think that there is a bug when a master page object's outline has center stroke alignment, and it is placed outside the page area. The outer part of the line width will not be drawn on pages where the master is applied (even if such objects are drawn correctly when copied directly onto the page).. I changed the master page object's stroke alignment option to "inside", and placed the rectangle at -3 mm, -3 mm, 426 mm wide and 303 mm high, and then it seems to be correctly drawn on pages where the master is applied. I also changed the width of the rectangle outline to 3mm (instead of 8pt). (Note that the document bleed was set at 3mm for all edges, not 5mm.) Affinity A3 template with 3mm Bleed.afpub
  5. Yes, it does overprint the black text. This is a screenshot from Adobe Acrobat Pro, black plate turned off (overprinting simulated): ...and this is a screenshot when the pdf has been opened in Photoshop in CMYK mode, black channel hidden:
  6. I placed the offending files in a new Publisher document and have played with it for a while, adding random objects, saving and saving as, but no problems experienced so far. The offending files are just fine and very plain so I cannot see they could themselves cause any problems. Do you have a possibility to save your document on an external drive to see that is not an issue with hard drive? (On the other hand, if there is an issue, it might naturally affect also operation of applications on the computer.) Have you run any diagnostic tool on your hard drive?
  7. Yes, starting from the "wrong" order of Ok and Cancel buttons.
  8. You're welcome. A white (CMYK 0, 0, 0, 0) rectangle on a master page would probably do the job without causing problems on pages where it is not needed. I am not sure how Affinity apps actually handle transparencies, but in the example job which was in CMYK color space (possibly because of color profile conversion done when I opened the file), I used CMYK white and the resulting pdf shows consistent background (already in Publisher immediately after the rectangle has been added). In InDesign it is possible to specifically define the Transparency Blend Space and typically it is the same as the document's main target color space, but I guess it has been made a choice because the one that is more useable may depend on complexity of the transparency effect and what else you have on the document that is affected by the transparency and in which color space (and also because the document often has more than one PDF export targets, so the blend space can be changed as needed). But the point is that it is good to have the background in the same application that creates the effect so that everying can be resolved in one go and nothing is left for an external renderer.
  9. The problem is that there is inconcistency in behavior. Mostly Publisher seems to "remember" the last settings (which is sometimes ok and sometimes not), when there is no way to make your own preference, and that would be ok here, too. But I also agree that All pages should be the default, and it is a nuisance to always set it back to "All pages" after having produced first a spread-based export. This still happens to me all the time.
  10. TOC links (that is, the links that are attached to TOC page numbers) are automatically generated and should not show there, but all manually added hyperlinks (e.g. those that you have created by selecting text and then targeted to a specific page within the document, or to a previously created anchor point) should show, as should url hyperlinks.
  11. How do the title/text hyperlinks show when you are in Publisher? Automatically created hyperlinks should not show in any way on the page, or in the Hyperlinks panel, either (they are implicit and will only show in the exported PDF)? The hyperlinks that show in the Hyperlinks panel are all manually created.
  12. I opened the TOCTest.afpub file in the release version and it does show the hyperlinks that are links to anchors. They also operate ok.There must be something that's corrupt in your file. When you insert a hyperlink via menu (Text > Interactive > Insert Hyperlink), it should automatically be added also in the Hyperlinks list (you do not need to add the hyperlink from within the Hyperlinks panel).
  13. It seems to be working with the current beta (, see attached. But could of course be something that only works with limited page formats... TOCtest_print.pdf
  14. I think that's the default operation -- conversely I'd like to know how the link can be extended to cover the whole TOC entry! I just did it manually by adding invisible boxes and then creating and attaching hyperlinks to them that point to anchors that have been added just below the headings on corresponding pages. This works fine and allows also updating the TOC without losing these links, so for me this is the solution if there is no way to have automatically extended TOC links. The page number hyperlinks (just around the page number) should be automatically generated when you insert (or update) TOC and have checked the heading styles to be included in scanning, and ensured that the page number column has check mark so that the TOC entry gets the page number. But do you actually have a generated TOC, or purely manually created and hyperlinked text frame (but possibly in TOC frame)? When you have the TOC panel visible, do you have any styles checked for inclusion? Have you tried if you can avoid the problem with column breaks (either in the TOC or in the Index) by using a paragraph attribute or TOC/index style with flow option for starting the entry at next column, similarly as I have done in the attached publication? I suppose this method could avoid mistakenly created overlarge hyperlink boxes. When you have the Hyperlinks panel active and go through the links, do they lead to correct anchors when you click "Go to Target" button? (and just fail when you create the PDF)? The following are updated versions of same files in earlier post: TOCtest.afpub TOCtest.pdf
  15. Interesting (because I'm not in urge of producing anything How are the superfluous TOC hyperlinks (surrounding the chapter headings) generated? I'd myself prefer to have hyperlinks extended to cover the whole TOC entry and not the mere page number so I typically end up stretching them in Adobe Acrobat Pro. So for me this would be desired behavior in certain kinds of projects (but link targets should naturally be correct!). Or are these manually made hyperlinks to Chapter entries made to TOC, and then you have anchors within the chapter headings (or on the same page) where these hyperlinks are meant to be pointing?
  16. To illustrate the role of color space, here is how the unflattened image, which was exported in CMYK color space, is shown if you force sRGB color space on it in Adobe Acrobat (the reddish blue parts have already been flattened against the white background while the purer blue has still a transparency value, so it gets its final blue tone in the renderer application that resolves the remaining transparencies). This simulates how the browser would show the source image's transparency cmyk blue against white in sRGB color space. But when you view the pdf in intended color space (CMYK), the blues get identical tones:
  17. The difference is explained by the fact that the part of the blue transparency that was originally on the white background, has already been "flattened" (that is, its effect is calculated and resolved, and it is now just a shade of blue), while the part that is on transparent background is still an RGB blue with "A" transparency percentage. The shade of blue that it will turn to, depends on the renderer application and the color of the background at the time the image is rendered, and even if it is flattened against white background, the blue may look different due to the differences in color space (e.g., the original effect of transparent blue against white was perhaps resolved using the Adobe RGB color space, while the browser that resolves the remaining of the transparencies is likely to render the image in sRGB color space).
  18. I do not think that this is a bug. As mentioned above, the effect of transparency is calculated against underlying colors. White background results in different effect than transparent background. See attached an edited document where white rectangle is placed behind all objects, and the PDF exported from the document. The background (and accordingly the outlook of the blue transparent object) is now uniform. picture frame and transparancy_whiterectangle.afpub picture frame and transparancy_whiterectangle.pdf
  19. Having a more thorough look on this. For me the the short delay at program launch is totally acceptable, and I have never felt it would be anything exceptional, but I now ran tests with launch times using InDesign, Quark and Affinity Publisher ("First time" means running after a fresh boot + 5 minutes, seeing that the processor is more or less idle; "Second time" means closing the app and immediately after reopening it, no concurrently running other tasks other than antivirus and other typical background processing): InDesign (CS6): First time: Program ready at 0:20, default document created, text frame added and font Zapf Chancery picked from font list and ABC added at 0:41, second time program ready at 0:07, saved doc opened, ABC selected by double click, font changed to Yu Gothic Bold at 0:25. QuarkXPress 2018: First time: Program ready at 0:35, default document created, text frame added and font Zapf Chancery picked form font list and ABC added at 1:16; second time program ready at 0:32, saved doc opened, ABC selected by double click, font changed to Yu Gothic Bold at 1:03. Affinity Publisher (beta 1.73.475): First time: Program ready at 0:20, default document created, text frame added and font Zapf Chancery picked from font list and ABC added at 0:58, second time program ready at 0:18, saved doc opened, ABC selected by double click, font changed to Yu Gothic Bold at 0:39. === InDesign clearly shines, but Affinity does very well, especially considering that it creates previews for all substyles for the font list from which the font is picked and the other two apps just create a list of family names and a preview for the default font for the family (the substyle being picked from a secondary list showing previews for just one family). As the delay seems to be related specifically to building the previews of the installed fonts (rather than just enumerating them), an app specific font cache itself probably would not have much effect on the matter. One solution would be just continue building the previews at idle time and provide an alternative font list without previews, which could be accessed e.g. from the Character panel. This way the complete font list without previews would be immediately available at program launch and the lists with previews would typically be completely finished within a minute or two. But as the test shows, the list can be used and builidng interrupted practically as soon as the program has launched. But considering that this test was done with about 700 fonts installed, which is probably quite average, I am not sure if this is really a problem. Perhaps there is a trigger with the number of fonts installed where things get remarkably worse, but I'd definitely suggest use of a font manager if projects are so varied that they require a constant and immediate access to a very large collection of fonts. The test was performed on a laptop with 16GB RAM, SSD, Intel Core i7-7700HQ CPU @ 2.80GHz), Intel HD Graphics 630 + NVIDIA GeForce GTX 1050, running latest version of 64-bit Windows 10 Pro (1903). UPDATE: There seems to be some variation in Affinity Publisher depending on which font, and how, it is selected. E.g., when scrolling down somewhere in the middle of the font list and then hesitating for a while, or trying to open the substyles dropdown, there might be unresponsiveness that can last 30 seconds or so, so the building process does not yield time for interactive processes well all of the time. So there might be point for creating a non-preview font list in the context of Character panel which would be lightweight and fast scrollable. On the other hand, I also found that typing in a few first characters of the font name (e.g. Helv) and then selecting directly the family name without trying to open the sub styles group, but instead selecting the substyle from the secondary menu, allows quick selection of font even when rebuild of font previews is clearly taking procesing time. Undecisive scrolling with the mouse may indeed be a painful experience, and if it seems to take time, it is better to just drop the task and try again with the suggested type-in initial letters + pick font family method.
  20. Just to check that there is nothing system specific, can you export from the attached test publication a pdf where TOC links, heading URL hyperlinks and index links operate correctly? The attached PDF is exported as (web) and Acrobat is just used to specify facing pages view and opening at whole page fitted in view. TOCtest.afpub TOCtest.pdf
  21. Can you post any of the broken documents here, I could have a look on one..
  22. I could reproduce it exactly as described. Please find attachments. The "Just text" link has a trailing space and is the only link that limits to the text itself (note that visually every link ends in the last character of the cell text, but you can see from the hand cursor that the actual hyperlink extends to the end of the cell, and at height of two cells, after the last cell of the row gets its hyperlink). I could additionally create an error where a link added to the last cell in the row (but with some empty cells before that) caused a three cells high hyperlink, and one that removed the other hyperlinks in the Hyperlinks panel. I cannot reproduce the error, though. The description Fennec gives is also a plausible explanation. I also tried to create a hyperlink to an empty cell, or to whole table cell already containing text, but could not create a working hyperlink this way (the link and underline character was visually applied just to the cell text itself, if there was one, and not at all, if there was not cell text). It would be great if hyperlinks could intentionally be created for full table cells (or area of cells), as well, but now this happens uncontrolled and unintentionally when trying to create link for the text within a cell, without adding the trailing space character. tablelinks_v02.afpub tablelinks_v02.pdf

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.