pixelated font after export as a pdf/x3:2003 file

[Bastian Holzheimer]

Hello, I use Affinity Publisher 1.7.1. on MacBook Pro (OSX 10.13.6).

I have a Text over a color gradient. When I export it as a pdf/x-3:2003 the font is pixilated.

When it is exported as a pdf(for print) the font is exported as a normal vector graphic.

Is this normal? I'm not sure where the Problem is. I had similar problems with older versions of Affinity designer.

The jpg below shows a zoomed in a.

Thanks!

 

[Bastian Holzheimer]

I've found a difference:

The font only gets pixilated when the edge of a photo lays over it. When the font lays over the photo there is no problem.

But one problem still exists:

When I export it as a pdf/x-3:2003 the font is pixilated.

When it is exported as a pdf(for print) the font is exported as a normal vector graphic.

I don't think that this is normal.

What do you think???

[mac_heibu]

If you export to PDF/X-3, transparency isn’t allowed. That means, transparent parts of your layout have to be flattened (= „combined“ with the underlying areas) Publisher actually achieves this (not always, but very often) by converting and combining these elements to an image. Therefore vector text sometimes becomes pixel text in this situation. Adobe apps are much more „intelligent“ by using image filled clipping areas instead whenever possible. (In your case, InDesign would simply spoken „fill“ the text with the respective parts of your image, thus maintaining its vector outlineS. Adobe – as the inventor of PDF – has much more experience with PDF output flattening and I bet, this behaviour will be optimised in Publisher from version to version.

But: In many cases, it is possible to avoid this behaviour by modifying the layout. Just have a close look at the attached sample file. You will see a text/image combination, built in 2 different ways – one will output pixelated text, the other will stay vector, when using PDF/X-3 specifications.

 

sample.afpub

[Bastian Holzheimer]

Thanks a lot for your detailled explination. Now I understand the problem. I suspect that it wouldn't be be possible to solve the Problem for my case in this way, because the picture in front of the font is a person, not a circle.

With pdf(for print) it works. Is it a big difference?

[thomaso]

Instead of a circle you may use of cause any shape as a vector mask or clipping path, even the form of a person.

Yes, there are fundamental differences between various PDF versions. On of them is the support of transparency, another for instance are specific color spaces.

[Bastian Holzheimer]

thanks a lot! it really works and looks great!

Edited July 13, 2019 by Bastian Holzheimer

[mac_heibu]

12 hours ago, Bastian Holzheimer said:

Thanks a lot for your detailled explination. Now I understand the problem. I suspect that it wouldn't be be possible to solve the Problem for my case in this way, because the picture in front of the font is a person, not a circle.

With pdf(for print) it works. Is it a big difference?

Yes. Most printing companies need „flattened“ PDFs (X-1, X-3). So you can‘t escape. 

[nwhit]

On 7/13/2019 at 2:09 AM, mac_heibu said:

If you export to PDF/X-3, transparency isn’t allowed. That means, transparent parts of your layout have to be flattened (= „combined“ with the underlying areas) Publisher actually achieves this (not always, but very often) by converting and combining these elements to an image. Therefore vector text sometimes becomes pixel text in this situation. Adobe apps are much more „intelligent“ by using image filled clipping areas instead whenever possible. (In your case, InDesign would simply spoken „fill“ the text with the respective parts of your image, thus maintaining its vector outlineS. Adobe – as the inventor of PDF – has much more experience with PDF output flattening and I bet, this behaviour will be optimised in Publisher from version to version.

But: In many cases, it is possible to avoid this behaviour by modifying the layout. Just have a close look at the attached sample file. You will see a text/image combination, built in 2 different ways – one will output pixelated text, the other will stay vector, when using PDF/X-3 specifications.

 

sample.afpub

In your sample, is the key to put graphics into a picture frame when overlaying text?

[nwhit]

In playing with this, I guess I'm not understanding how to overcome this issue. I tried putting both a APh TIFF and the actual APh graphic into a Picture frame and still get the rasterization of the Artistic text around/under the graphic element when exporting with X-3. Thus I guess I am missing something important. 

In all the beta testing on Publisher, I never came across this since I had not tried overlaying a graphic item over text, but this is a big deal for a lot of work on print shop output work for clients. Hopefully there is a simple, satisfactory workaround.

I also just tried the same thing in ID CS5 exporting with X3 and it does not raster the nearby areas of text.

Sample of APub beta 422 pdf-X3 output.

 

sample text under graphics - X3 output.pdf

[mac_heibu]

Can you attach the .apub document with embedded images?

[nwhit]

Attached. 

 

 

sample text under graphics - upload.afpub

[thomaso]

On 7/14/2019 at 11:12 PM, nwhit said:

is the key to put graphics into a picture frame when overlaying text?

The key is, to place no kind of transparency on the text but using any vector shape as mask instead.

A picture frame works as mask and cuts off the area around its image inside. A picture frame with rounded corners cuts off the transparency in your logo.png and limits the rectangular shape by its rounded vector shape. This way no transparency of the .png is placed on the text but cut off by the masking frame.

The shadow within your .tif is not that easy but works in this case because the shadow of the circled image does not touch the text.
To avoid transparency here you separate the 'coin' and its shadow by a mask (as you did already) for the image but ...
... limit the mask shape to the 'coin' circle and 
... add the shadow by an object underneath. Therefore you create
... a second circle in size of the 'coin' and
... limit its upper edge with a rectangular mask, so it does not touch the text and
... apply the shadow to this new object:

sample text under graphics _ot.afpub

[mac_heibu]

Thomaso is completely right.

The solution is not, to simply place an image into an image frame. The solution is, to introduce no transparency in front of text – and you definitely did it, as you can see in the screenshot (I coloured transparent areas in cyan).

[nwhit]

I think I understand now. The Picture Frame must be the exact size of the graphic element and cannot include anything transparent. Thus drop shadows have to be manually created and added in a masking Picture Frame that does not intersect underlying text. 

While I now understand how you did this, I can also see that this is a HUGE PITA. I'm thinking that until Serif can solve this issue, my production company will have to continue to use our old CS5 ID for anything requiring CMYK-X3 output for a print shop/print job. Just way too much to be concerned about when creating something if we're suddenly back to the old days of difficult transparency and drop shadows (yes, I remember those days!). 

I've been really liking Publisher throughout the beta process and have been using it to produce several web pdf publications, but this issue really spells trouble for doing any print shop cmyk work. Just far too easy for someone to forget about the problem and how to get around it, plus the extra time and cost to the client to watch for and fix the issues in a publication. Yes, a designer can work around the problem, but with extra time and cost to the client, plus the chance of problems. 

Never would have expected something so simple to be "missing" in Publisher, so I am very saddened about having to go back to ID for some of our work. Hopefully one of the mods can assure us that this will be fixed/upgraded soon.

[nwhit]

From looking at the workaround, it then appears that there is no way possible to have a drop shadow or transparency on top of text. Is that correct? 

And can I also assume that even if the graphic with a drop shadow or transparency over text were created in AD or APh and imported into APub, it still would not work with a cmyk-X3 export? Imported/placed in any format????

Eliminating drop shadows and transparency over text is a VERY design-limiting issue. Over the years, we've simply become very spoiled using these techniques over and over without issue. I just hope Serif can resolve this issue.

[mac_heibu]

——> „Never would have expected something so simple to be "missing" in Publisher“

Please allow me, to laugh out loud! Transparency reduction strategies is a branch of scientific research in the printing industries. It is all but „simple“!

(Perhaps you get a slight feeling now, why there is such a difference in InDesign’ and Publisher’s pricing level! :))

[nwhit]

Perhaps not simple (improper word choice), but it was resolved many, many years ago. Over the years, my firm has done thousands and thousands of drop shadows and transparencies over text ever since that capability was first introduced way back when (I go all the way back to PageMaker v1 and the intro of the very first laser printer).

I'm not trying to trivialize the amount of work it has taken Serif to get where they are, but to move forward on the premise that we as designers cannot use transparency or drop shadows over text is not a reasonable offer. Simply far too restrictive for most client's print projects. 

But as I said, I love Publisher and look forward to using it for RGB web work. And I am hoping that they can resolve this issue so that we can then use it for cmyk print output. 

[thomaso]

4 hours ago, nwhit said:

Over the years, my firm has done thousands and thousands of drop shadows and transparencies over text ever since that capability was first introduced way back when (I go all the way back to PageMaker v1 and the intro of the very first laser printer).

Sure? – The PDF format was published in version PDF 1.0 in 1993 and no PDF did exist at the time of PageMaker v1 (1985).
PDF/X-3 (PDF 1.4) was published in 2002 and got an update in 2003 (the version available in AfPub).

The lack of transparency in PDF/X-3 is not a missing feature of AfPub or a special ability of ID but is defined in the PDF standard for X-3, which simply says that transparency is not allowed in X-3. https://www.prepressure.com/pdf/basics/pdfx-3

You may, of cause, also in AfPub select the PDF/X-3 export preset and alter its settings in the "More" options. But then your result will not conform to the X-3 standard. Also you can export in AfPub as PDF 1.4 (which is same PDF base as for PDF/X-3) but without the X-3 attitudes. Such a 'normal' PDF 1.4 (not PDF/X-...) indeed does support transparency.

In PDF the transparency is not a matter of ID or AfPub but of the PDF standard version. The first PDF/X which supports/allows transparency was PDF/X-4, published in 2008.

So I assume you first did not export a PDF at all (but for instance EPS or PS instead), and later, in your time using ID CS5 for "thousands of thousands", you did not really export a PDF/X-3.

If you still think you exported X-3 from ID then I'd like to have a look one of your PDFs using transparency without rasterizing.

[nwhit]

26 minutes ago, thomaso said:

Sure? – The PDF format was published in version PDF 1.0 in 1993 and no PDF did exist at the time of PageMaker v1 (1985).
PDF/X-3 (PDF 1.4) was published in 2002 and got an update in 2003 (the version available in AfPub).

Perhaps what I said did not translate correctly. There were MANY missing technologies when I started converting print shops, newspapers, universities, ad agencies, etc. in the early days. But when opacity and drop shadows eventually evolved and improved, it made things easier/faster/better/affordable. And the evolution of the PDF standard was also a great help.

27 minutes ago, thomaso said:

If you still think you exported X-3 from ID then I'd like to have a look one of your PDFs using transparency without rasterizing.

Just did an ID CS5 export to PDF X3. At maximum magnification in Acrobat Pro and Preview, I am not seeing any pixelation of the type. Perhaps I did something wrong. Perhaps it is there and my old eyes can't see it. But based on this test, it is much better (and perfectly acceptable to clients) as opposed to what I get from Publisher X3 output. Why? I have no idea. I'll leave that to the coders and students of the science. But as a designer, we need to put out product for clients and I simply can't see eliminating the use of transparency/drop shadows over text for those hard-copy printing clients. Not when I seem to be able to (still) get acceptable results using ID. Or at least it appears to okay. 

I'm not trying to argue technology, historical dates, science, licensing, proprietary technologies, etc. We as a firm, and the many other firms I set up over the years, have used these design styles for an awful lot of work, whether that's 10 or a thousand. I seemingly can still output PDF X3 from ID CS5 and get acceptable text rendering results for posters and other printed materials. It appears, based on this thread, that perhaps Publisher may not have that ability. Fine. As I said, I love Publisher and will use it for web work. Just wish it weren't so.

And please, I'm not trying to start an argument. Nor am I challenging your knowledge of the subject. You obviously understand the underlying technologies much better than I ever wanted to. I'm passing along my needs and my experience using ID CS5. which appears to work acceptably -- unless I'm not seeing something correctly.

Most importantly, I'm just passing along my requirements for doing everyday client work. While there is a lot less actual printed materials work being done today (I have friends in the printing business and others who are now out of it due to the downturn), there is still the occasional need, so need a method to keep doing these things. And I sincerely thank you and others for your help on this and several other issues here on the various Affinity forums. Always try to learn. And always try to understand. Some things I have to simply accept since I don't have the time to relearn too many things.

Right now, for example, I'm really fighting the issue with Affinity apps where you cannot save/name the "Studio" setup or workspace. I and others are struggling with betas that crash, mess up, etc. and the workspace setup is lost. And with the new Studio Link, it's even more disastrous if you've taken time to set up each Persona to your working style. Why can't we save workspaces? I have no idea. All I know is that many apps such as FCPX are based on the ability to set up multiple workspaces for different workflows. Seems like it is doable, but I would not and cannot argue the technology involved. Just something many of us need to make Affinity apps really usable on a day-to-day basis. 

Again, I apologize if I have seemed argumentative. Didn't mean it that way at all. I want Affinity to succeed and I appreciate you sharing your knowledge. 

sample text under graphics - X3 output - ps.pdf

[mac_heibu]

@thomaso: The only thing to add: InDesign „solves“ the problem of this thread by converting the glyphs, which are overlayed by (semi)transparent images to paths, filling this path just like a clipping path with the respective parts of the overlaying image and placing the original image behind the text. This flattening technique in connection with fonts was introduced years after the initial version of InDesign and was result of years of investigations and research and is applied to the sample file, which nwhit attached in his last post.

So: Yes, it is possible to reproduce transparent text overlays in print ready PDFs, but to expect this sophisticated technique of an initial version of a layout application is simply inadequate.

[nwhit]

31 minutes ago, mac_heibu said:

@thomaso: The only thing to add: InDesign „solves“ the problem of this thread by converting the glyphs, which are overlayed by (semi)transparent images to paths, filling this path just like a clipping path with the respective parts of the overlaying image and placing the original image behind the text. This flattening technique in connection with fonts was introduced years after the initial version of InDesign and was result of years of investigations and research and is applied to the sample file, which nwhit attached in his last post.

So: Yes, it is possible to reproduce transparent text overlays in print ready PDFs, but to expect this sophisticated technique of an initial version of a layout application is simply inadequate.

Very much appreciate the explanation. And I understand that the many, many issues facing Serif/Affinity in making their apps as competitive and as "pro" as possible are very, very challenging, especially given their highly reduced revenue stream/business model. 

To once again clarify, my only point in this thread is that in my opinion this is a needed "feature"/capability for many pros who are used to using this technique and need to continue to do this, so I am hopeful that Affinity can solve this issue, as well as the many others it faces. 

But again, thank you for the clearer explanation. Doesn't solve the issue but certainly interesting to know. 

[nwhit]

55 minutes ago, mac_heibu said:

converting the glyphs, which are overlayed by (semi)transparent images to paths, filling this path just like a clipping path with the respective parts of the overlaying image and placing the original image behind the text

Interesting! I just opened the ID X3 PDF in ADesigner and see what you mean on how they are doing it. Interesting! Does the job, so I can't argue with how they do it too much!

[thomaso]

10 hours ago, mac_heibu said:

InDesign „solves“ the problem of this thread by converting the glyphs, (...)

So: Yes, it is possible to reproduce transparent text overlays in print ready PDFs, but to expect this sophisticated technique of an initial version of a layout application is simply inadequate.

Ah, Thank you mac_heibu, I haven't been aware of this ID specific workaround. – Opening such a PDF in AfDesigner shows those white lines again (depending on zoom factor) which drove me crazy many years ago – until I finally avoided to flatten on export and used PDF 1.5 or newer instead, or even just transferred the packed ID file to print-shops which refused to work with PDFs with transparency.

9 hours ago, nwhit said:

Interesting! I just opened the ID X3 PDF in ADesigner and see what you mean on how they are doing it. Interesting! Does the job, so I can't argue with how they do it too much! 

Yes, indeed an interesting info. (which also makes a lack of my knowledge obvious, Sorry!).

But different to you I don't like this special handling in an X-3 PDF of ID which increases the complexity of objects within such a PDF by adding many masks. To me it appears more like a (bad) work-around to release designers from caring for it. Which, actually, today is not necessary any more since newer PDF versions were developed and published as possible standard.

So, looking at the amount of objects and layers in such a PDF from ID – compared to the simply 3 (!) layers in a proper AfPub workflow – makes me see today this InDesign way more as an unprofessional compromise. (like a craftsman trying to conceal his unprofessional work with additional objects like more screws, more paint, more of anything.)

Nowadays I rather expect print-shops not to insist in flattened PDFs but to update their RIP (hard- or software) to the nowadays technology (which, yes, can demand relevant investment). And, if they want the safety of PDF/X, then at least PDF/X-4 should be the requested version, which exists since eleven (!) years.

That finally means I would, again different to you, not blame Affinity for not supporting or offering such kind of old-fashioned technology but rather adapt and update my own workflow to the newer standards + request the according from my print-shop, and of cause, also from the company I am working in. I am aware it can be hard and time and money consuming at first, especially if I tend as somebody who prefers + insists to do things as they "always" have been done in the past.

Everyone already did part with something familiar, the good, and would not want to return there today, even though the change formerly seemed so "unnecessary" at first. PagePlus, PageMaker, Freehand, Windows 7, macOS 9, fax machine, pre-press with reproduction camera and lithography, EPS, Distiller, ISDN file transfer, ... and, one day, this PDF/X-3 flattening weird wild work-around with its complex compromise: