Jump to content

Recommended Posts

Which PDF setting renders body type the best? I regularly produce a 26 page brochure using Affinity Publisher. NONE of the AP PDF settings would render really crisp small type. The closest I got to an acceptable result was creating my own custom settings with No Downsampling. It is acceptable, but not really crisp (see the page sample I have attached to this question). I hate to say it, but the PDF renderings I used to get with InDesign were always crisp. I think that is because InDesign PDF's included a setting option to "Include All Fonts". What can I do to make sure all fonts are included with my AP PDF's? Is there something I am not understanding? Can anyone help me please? — FYI, I am using a MacBook Pro with 27" Apple display.

WW wText Sample.pdf

Share this post


Link to post
Share on other sites
On 11/19/2020 at 9:49 PM, ABHULtheELF said:

NONE of the AP PDF settings would render really crisp small type.

An interesting and important observation. I think what happens here is that you have a CMYK document with K100 text which you then export to RGB for digital viewing. Affinity apps seem to convert K100 to something like RGB 30 30 30 (dark gray), depending on the underlying CMYK profile, while Adobe apps will produce pure black RGB 0 0 0.

It is obvious that dark gray text will look less crisp than pure black. Here are screenshots from regular and retina displays when outputting to digital use PDF from a CMYK document with K100 text:

smallprintrendering_rgb_regular.thumb.png.1cd589731a38cc1ae0b1a3f848243a74.png

smallprintrendering_rgb_retina.thumb.png.9e321f9b2f0f44263bc2fa0a5892b5b2.png

 

smallprintrendering_rgb_apub.pdf

smallprintrendering_rgb_id.pdf

 

Share this post


Link to post
Share on other sites
On 11/19/2020 at 3:27 PM, anon2 said:

Is the problem in the printed document or is it when the PDF is viewed in an app? If the latter, with which app are you viewing the PDF?

The problem is the latter (It only happens viewing the PDF on a computer screen. The printed copies are fine.) The problem is, most of the people who receive the 26-page document will most likely view it on their computer, rather than printing it out. To answer the other part of your question, I am viewing the document in Adobe Acrobat Pro (which is the default app that converts all my Affinity docs into PDF.) However, the entire 26-page document is emailed to WintersWilden's potential clients so they can view it on their own screens or print the document out on their own printer.)

Share this post


Link to post
Share on other sites
On 11/19/2020 at 7:15 PM, Lagarto said:

An interesting and important observation. I think what happens here is that you have a CMYK document with K100 text which you then export to RGB for digital viewing. Affinity apps seem to convert K100 to something like RGB 30 30 30 (dark gray), depending on the underlying CMYK profile, while Adobe apps will produce pure black RGB 0 0 0.

It is obvious that dark gray text will look less crisp than pure black. Here are screenshots from regular and retina displays when outputting to digital use PDF from a CMYK document with K100 text:

Yes, it is a CMYK document, and here is the thing—The body type in this document is not 100% Black, but rather is supposed to render 70% Gray tone. So, If I understand you correctly, then the problem started when I selected K70, instead of rendering the type in CMYK numbers that would equate to K70. Is that right? And if so, what CMYK setting would render a 70% Gray tone?

Share this post


Link to post
Share on other sites
4 hours ago, ABHULtheELF said:

Yes, it is a CMYK document, and here is the thing—The body type in this document is not 100% Black, but rather is supposed to render 70% Gray tone. So, If I understand you correctly, then the problem started when I selected K70, instead of rendering the type in CMYK numbers that would equate to K70. Is that right? And if so, what CMYK setting would render a 70% Gray tone?

Hmm, no, I do not think that this could explain it in that case. My explanation was based on assumption on using K100 = ({Black] swatch) in InDesign, as only 100% of black would be interpreted as unmanaged RGB 0, 0, 0. Any percentage of [Black] would be interpreted according to the underlying color profiles also in InDesign, and as I tested this, Adobe apps and Affinity apps produce equal color values whenever anything else than solid black was used. 

Would it be possible for you to provide a sample .afpub document of a page that experiences this problem?

Share this post


Link to post
Share on other sites
On 11/27/2020 at 2:52 PM, Lagarto said:

Would it be possible for you to provide a sample .afpub document of a page that experiences this problem?

YES!—I have attached a single page that shows it best. Note in particular that the lower-case letter "a" in the body type probably reveals the problem best when converted to PDF.

WintersWilden_Brochure_ONE_PAGE.afpub

Share this post


Link to post
Share on other sites

I tried with this but cannot see any difference when producing a PDF with identical specs. Could this be related to color modes, though, because there are differences between InDesign and Publisher when they output text. As mentioned, InDesign can keep K100 as RGB 0, 0, 0 when converting CMYK documents to RGB for digital viewing, and it also keeps RGB defined colors as RGB when exporting to PDF/X-3 or PDF/X-4 (as in your sample document which had the text defined as RGB 102, 102, 102), while Publisher always converts text to CMYK even if the export mode (like PDF/X-3 or PDF/X-4) does not require it.

But with your example file, where body text had RGB 102, 102, 102 defined as fill color, and when exporting to PDF/X-4, I could not see any rendering differences (either when viewing at 100% zoom rate, or zoomed in closer) between Publisher and InDesign created PDFs even if Publisher had made the color conversion to CMYK and InDesign kept the color as RGB (after all, when using an identical profile, both definitions produce the same RGB values when rendering on screen).

It would be (marginally) different if the original text had its color defined as RGB 0, 0, 0 (pure RGB black) as then Publisher created PDF would convert the color values to CMYK while InDesign created would not. On a color managed app like Acrobat Pro, which would read the rendering intent in case the file has one, both files would produce identical rendering (as Acrobat would show the internal RGB 0 0 0 values using the color profile based adjustment), but in non-color managed PDF viewer the InDesign created text would show as pure RGB black (0, 0, 0) while the Publisher created CMYK black would be rendered as dark gray. The difference is not big, though, but can be measured. It might show if the font has very thin lines (as Helvetica Neue can have), and when viewed at certain zoom rate and certain srceen resolution.  

But as said, in addition to these color differences, I could not produce any difference in rendering of text between Publisher and InDesign created PDFs when using the same source file, same color profiles and same viewers.

Share this post


Link to post
Share on other sites

Lagarto — The attached magnified screenshot will show you what I am seeing. It seems to be happening only with the lower case letter "a" and only in the PDF file. The funny thing is, if I magnify this type in my viewer, (like you saw) everything looks normal. It is still a real puzzle to me. Maybe I have one or more incorrect settings either in my Affinity Publisher document or in Acrobat Pro?

screenshot_93.png

Share this post


Link to post
Share on other sites

This is an odd problem. Can you reproduce this with the attached PDF files which have letter "a" typeset in each font of Helvetica Neue family in various point sizes and shades of black and RGB gray, exported from Publisher and InDesign.

I do not experience any rendering difference between these two files (viewed with Adobe Acrobat Pro 2020).

Does this happen with other fonts, as well? If so, do the fonts use the same technology (TrueType, OpenType TrueType or PostScript flavor, Type 1, etc.)? Does this happen with muliple PDF viewers? Are there differences if you convert fonts to curves either by using Layer > Convert to Curves, or by using the Export setting ("Text to Curves" option selected for the setting "Embed fonts")?

Font_rendering_id.pdf

Font_rendering_apub.pdf

Share this post


Link to post
Share on other sites

Here is a comparison of your original file and when it is imported (as PDF) to Publisher 1.9.1 WIndows version and the embedded fonts are mapped to Helvetica Neue version I have installed on my Windows computer (Adobe FontFolio 11.1 OpenType PS flavor):

a) Your file at 200% on non-retina regular display (clear problems with rendering a at certain zoom rates, like 200%):

original_example.png.f1d8ceb1d2e350c0c80d3ae076f7c401.png

b) Exporting the same text from Publisher using PDF (export) and Adobe OpenType PS flavor of the font:

hn_from_fontfolio11_ot_psflavor.png.07f895421635c870e6654250eb9c925c.png

No problems whatsoever. I can try this same on macOS and the OT TrueType flavor that comes with the system, but I cannot believe there could be a difference in font quality, and clearly there is no problem with Affinity Publisher (and I cannot believe it would behave worse on macOS), so initially it seems there is something system speciic.  

c) Now tested this using Publisher 1.9.1 on macOS (Big Sur 11.2.3) and using the Helvetica Neue OT TrueType flavor (that also seems to come from Adobe), and strange, there is definitely rendering difference, which shows when viewing on a non-retina display (again, at 200% zoom rate):

hn_macos_ot_ttflavor.png.6bc0c8c593881c3d4860320d8bef33b7.png

It is not as bad as in your original example but there is clearly a tendency on letter a to get unnecesarily thin as if hinting of the font did not work properly, yet this is TrueType flavor which as far as I know should handle hints better than a PS version. I need to examine this further by using Adobe apps and QuarkXPress in the same environment. I have always thought that hinting is not dependent on the software that embeds the font, but you mention that you cannot experience this problem when exporting from InDesign.. I'll make some further tests... UPDATE: Done testing with other apps and exported to PDF but results are similar so it does not seem that this could be related to Affinity apps. Will test next if the macOS TrueType flavor Helvetica when installed on Windows renders better there than on macOS.

UPDATE: Yes, it seems to be so that the "same" OT TTF flavor font renders better on Windows than on macOS:

ot_ttf_rendering_windows.png.5220ea7ab13a47ad78009e8904c245e1.png

There are several notes though: 1) I had to generate this font again by using FontLab Studio as the fonts extracted from the TTC collection were somehow protected and became corrupt, so it is not clear that the fonts are identical even if the same master and unchanged parameters have been used. 2) I cannot see any rendering problems on macOS with this font when viewed on a 4K display 3) I cannot see any rendering problems, either, when viewing this font on Windows when using 4K resolution. But the core of the problem is that this font seems to be rendered a bit squashed in vertical dimension when using regular HD resolutions (or lower), which results in e.g. the double-story "a" middle line to become thinner than designed, and at certain zoom rates nearly disappear. This problem only occurs in the TrueType version of this font, and it seems, only when the PDF file has been created on macOS, or when macOS version of the TrueType font is used. The rendering error itself, when viewing the PDF file with embedded font, can be seen on either system. I know far too little about font technologies to be able to deduce anything from this, but it seems that using PS flavor of OpenTypes produces more compatible results when working in macOS environment. I might test this later by installing the PS versions of this same font on macOS, but here is Helvetica Now rendering produced from your file on macOS, and viewed on non-retina display, and rendering is definitely better than with the TrueType OT version of Helvetica Neue that comes with the operating system:

ot_ttf_rendering_helvetica_now_regular.png.d506cba5fcc48d6c1ae239c75ea32c19.png

But as can be seen, the metrics are different so you cannot simply just substitute Helvetica Neue Regular with Helvetica Now Text Regular.

Share this post


Link to post
Share on other sites
On 11/19/2020 at 8:49 PM, ABHULtheELF said:

FYI, I am using a MacBook Pro with 27" Apple display.

WW wText Sample.pdf 515.39 kB · 17 downloads

In 10.14.6 I can't make this issue occur. Neither in Acrobat Pro X nor in macOS Preview and in APub neither via Place + Passthrough or Interpret, nor via Open.

1012955799_heveticaneue-pdfpreviewzoom200.jpg.43296545f61ea662761322ddcacc76b3.jpg

543556226_heveticaneue-Openedzoom200.jpg.04633088b2072d0a6aad1e46a9296c86.jpg

I assume the issue is caused by your specific Helvetica font file(s).

On my mac Helvetica Neue is part of macOS system fonts (Linotype TrueType) but without "Condensed Light". Though I have also Helvetica Neue by Adobe (Postscript) its "Regular" appears to be named differently "55 Helvetica Neue". Furthermore according to the Acrobat property info in your PDF a TrueType, not a Postscript font is used.

Do you see the issue in the attached PDF? It is an export from your PDF after Opening it in APub. (the heading in font "NowDisplay" doesn't show correctly because I don't have this font):

WW wText Sample__Open–>Export.pdf

If you don't get the issue with this PDF you might check your font files (versions / dates). In 10.14.6 it appears to be version 13.0 of Linotype TT from 2019.
(and here it's Adobe Postscript for condensed light or alternatively 55 for regular)

2080197190_helveticaneue-macosLinotypeTT.thumb.jpg.9e75024f31c700bd3d2abe8d5f47e90f.jpg

359829732_helveticaneueAdobepostscriptregular.thumb.jpg.44cc90c2cca5c9882b0d3bd29eb6dc0f.jpg

14678257_helveticaneueAdobepostscriptlightcond.thumb.jpg.2a4752e3f9a2ed78d378f64c112f0fff.jpg

 


macOS 10.14.6, Macbook Pro Retina 15" + Eizo 27" // Affinity preferred in Separated Mode + Merged Windows

Share this post


Link to post
Share on other sites

@thomaso -- your export file shows the same rendering problem as what I demonstrate above when I reproduced this error on Helvetica Neue Regular on macOS Big Sur 11.2.3 and Publisher 1.9.1. The problem is not nearly as bad as in the sample file by OP, but shows vertical squash that makes the middle of the double story a line to become thinner. The glyphs appear to be 1-2 pixels lower than they should. There are no problems when viewing the rendering in 4K so you need to use lower resolution to see this.

EDIT: Here is a layered Photoshop file that shows different renderings when viewed at 200% on a non-retina display, screenshots grabbed from Adobe Acrobat 2020 Windows version. The layer showing the OT TTF flavor (basically the macOS Helvetica Neue Regular installed on Windows) should not be paid too much attention to, as it has been regenerated with FontLab, so it is not exactly the same font as on macOS. But it shows similar distortions and squashing than the macOS font. The topmost layer, the OT PS flavor, shows IMO correct rendering.

hn_renderings.psd

...and here is a comparison of Helvetica Neue PS and TTF version renderings (both from Adobe, the PS version from FontFolio 11.1 and the latter the system font that comes with the operating system), when viewing the PDF exports at 200% zoom rate:

hn_renderings_puremacos.psd

UPDATE: I tested this now also purely on macOS Mojave with non-retina displays and can confirm the same difference between the font technologies.

Based on all this testing I did not come much wiser. It appears that this is somehow related to legacy technologies involved in production of the original PDF sample that shows clear problems with rendering of specific glyphs (especially "a") in this font. But what is the crucial factor that explains the problem? Similar problems but in much smaller scale can be traced back to use of TrueType OT font instead of the PS flavor of the same font (even by the same manufacturer). Perhaps use of older macOS operating systems or specific hardware (retina vs. non-retina?) makes the error bigger? Or are there mixed platforms involved in production of these files? Why the error would happen when using Affinity Publisher but not when using InDesign (as stated by the OP), could not be explained by tests that I have been running. As far as I know similar PDF export settings have been used all the time, and as long as fonts have been embedded, I do not think that the color mode, export DPI, subset embedding etc. could explain the difference. What is clear however is that when viewing on retina/4K displays, both font technologies produce equally good rendering where these kinds of problems do not exist.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • 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.