Quark 2015 changing placed PDF's upon output

Discuss PDF Export and Print functionality of QuarkXPress 2015, 2016 & 2017, including PDF/X workflows

Re: Quark 2015 changing placed PDF's upon output

Postby MikeWenzloff » 01 Dec 2015, 17:41

Try exporting as a pdf/x-1a.

If the PS file is that large, you may need to export the pdf in ranges and combine the output pdfs.
MikeWenzloff
 
Posts: 1171
Joined: 05 Jun 2013, 12:55

Re: Quark 2015 changing placed PDF's upon output

Postby Matthias Guenther (Quark) » 02 Dec 2015, 04:05

Hi Bill,

yes, I have seen the thread and Mike also alerted me. We need to be able to reproduce the behavior first, before we can comment on this.

Your files definitely help to analyze this. Will comment on this once we have a result.

Thanks
Matthias
Feel there should be more chatting, more tips, more user interaction?
Join us on Facebook, a forum-like group with over 2,000 QuarkXPress fans interacting:
http://www.facebook.com/groups/quarkxpress



Image
User avatar
Matthias Guenther (Quark)
Quarkian
Quarkian
 
Posts: 5270
Joined: 04 Jun 2004, 15:06
Location: http://bit.ly/QuarkHamburg

Re: Quark 2015 changing placed PDF's upon output

Postby max.peter » 02 Dec 2015, 08:35

It is weird! I usually can distill PS files larger than 2 GB (even 3 or 4 GB), what is about that limit of 2 GB?
Every day is a good day to learn something new.
User avatar
max.peter
 
Posts: 1532
Joined: 11 Sep 2010, 12:35
Location: Romania

Re: Quark 2015 changing placed PDF's upon output

Postby UtahLlama » 08 Dec 2015, 11:05

I have had a look at the pdfs you supplied and have some theories.
It would still be expected that Quark can not parse all objects which could be in a PDF.
Quark appears still to have no mechanism to pass a placed pdf through unchanged.


The first pdf is created by Photoshop CS5.1
The second pdf is created by InDesign but contains some similar objects.

The first pdf appears to made up in just three objects, according to pitstop there are just three images each the same number of pixels, at least two of which are masked by clipping paths in the shape of text. There is an embedded font but it would appear that is used perhaps for Photoshop private data rather than the text.

Once this pdf has been through Quark the clipping path text is surrounded by a much tighter cropped box containing the image It is this image that is now reported to have transparency. In the Original pdf Pitstop’s wireframe mode shows the text clipping paths without a tight bounding box, however if you use Acrobat’s Edit Image tool selecting the image that contains the text colours, highlights the tighter box (the one that is appearing after being through quark) even though this is invisible to pitstop. Editing the image in Photoshop results in the image opening up at the full size with a lot of white. I’m guessing that there is some form of implied transparency or mask over this white area. I’m also guessing that whilst this is invisible to pitstop it is not invisible to quark’s internal pdf to postscript process.

I’m guessing that when you save a Photoshop pdf with text layers, that clipping paths in the shape of text with the image content in place behind, would be a common construction. If put together in Photoshop layers there would also be large areas of transparent (chequerboard) pixels. If you open a Photoshop document without the fonts you get a warning but the appearance remains intact unless you try to edit the text and the whole text block flips to a default font. Saving like this would allow edibility in Photoshop and vector quality output from InDesign, however this depends on selecting the relevant compatibility check boxes if saving as psd with pdf compatibility or pdf with psd compatibility, again I’m guessing this one has been saved as a Photoshop pdf but without the Photoshop compatibility.


The second pdf has objects similar, when I place into Quark and output to pdf the top right letter T is shifting position, as it is a clipping it is no longer falling over the image so appears to half disappear. I am not really seeing any other difference on output, perhaps I’m not looking carefully enough.

There was another thread here where Text was disappearing from psd files through quark10, it is possible this is related.
viewtopic.php?f=18&t=26774


In the old days the pdf is converted to postscript for JAWS to consume and create a new pdf.
It would be good if someone technical could explain in detail what is happening to placed pdf when Quark2015 Exports to pdf.
2015 uses Callas?
is able to pass transparency in a placed pdf through to the new pdf?
is able to color mange separate pieces of the placed pdf?
User avatar
UtahLlama
 
Posts: 205
Joined: 18 Sep 2012, 08:39
Location: The Grand Line

Re: Quark 2015 changing placed PDF's upon output

Postby nagarj » 04 Jan 2016, 15:40

I have a new set of test files for this problem. They show how Quark 9 and Quark 2015 output a series of flattened, fully-preflighted placed PDF files using each of the transparency output options available:

https://www.dropbox.com/s/hpfhbg57i9kie ... s.zip?dl=0

You can see how the native transparency output setting (the Quark 2015 default, and necessary for many workflows) ruins type, whereas the flatten and ignore transparency settings do not. Quark 9 outputs this type OK with all transparency output settings. Something has changed, and not for the better. We just had a very large book-length project ruined by this problem, with great time and expense required to get useable output from Quark 2015.

I used Quark's direct PDF output, but the results are the same if you create the PDF's via Postscript and Distiller.

You can also see how Quark 2015, when set to export transparency natively, actually introduces transparency into fully flattened placed PDF's. For some reason, Quark is radically changing the structure of those PDF's upon output, probably leading to the font corruption. These PDF structure changes go way beyond introducing transparency, as will be evident upon inspection with Pitstop or similar tool.

I will attempt to get Quark tech support to investigate this. In the meantime I'm hoping someone here can help. A previous poster kindly reproduced the issue, so I know it's not anything specific to our systems. I'd think ours is a very common workflow, with placed PDF files, so I'd expect many others are suffering as we are. If not, it would be great to know why.

Thanks,
Bill
nagarj
 
Posts: 20
Joined: 24 Nov 2015, 15:26

Re: Quark 2015 changing placed PDF's upon output

Postby UtahLlama » 07 Jan 2016, 12:14

Hi Bill
I've looked at your before and after pdfs, I hope someone at quark can take a look too because its a good spread of similar problems.

My findings:
Page 1 and Page 2, Pitstop identifies the items going wrong are "Clipping Text Line" objects, so theories are the same as my post above.
Also did you notice on Page 1 Quark9 messes this pdf advert up too, spacing the text the other way.

Page 3 pdf was from IDCC2015, Pitstop identifies the item going wrong as "Text Line" object.

Page 4, the object in the pdf before placing in quark is an "Image Mask" at 700ppi, after going through Quark it is unchanged except when output via Q2015 with Native Transparency when it becomes corrupt and is now converted to "Image" at 700ppi

Page 5, Font Subset in the original pdf is TrueType, Ansi Encoding, (produced from IDCS6).
after Flattened Export from 9 the Font Subset becomes TrueType, Roman Encoding
after Ignore Transparency Export from 9 the Font Subset becomes TrueType, Roman Encoding
after Native Transparency Export from 9 the Font Subset becomes TrueType, Custom Encoding
after Flattened Export from 2015 the Font Subset becomes TrueType, Roman Encoding
after Ignore Transparency Export from 2015 the Font Subset becomes TrueType, Roman Encoding
after Native Transparency Export from 2015 the Font Subset becomes TrueType, Custom Encoding

Page 6 (is produced by IDCS5.5) and is the same Encoding as Page 5 except for
after Native Transparency Export from 9 the Font Subset becomes TrueType, Custom Encoding

Note there are other Ansi Encoded fonts in the before and after pdfs so it is not a hard and fast rule to change the encoding.


Are there lots of people with the same workflow? I'd guess not, over the years I've put many pdfs into InDesign and not really checked the print pdf for this sort of content corruption since about CS4, with Quark it has always been check and double check placed pdfs. Quark 4 5 and 6 would mess up more times than not Quark7 and 8.0 would produce absolute train-wreck pdfs when flattening, Quark 8.1 finally gave us Native Transparency output which helped enormously. All through this period the safer workaround really was to save all pdfs as EPS and place that instead, if you had Pitstop often it was worth outlining the fonts too! Quark 9 I never really used but I've seen enough messed up pdfs to not trust it. For me Quark 10 and 2015 are improvements, but for you maybe not?


It would be really nice if someone technical (GrahamPM) could join the discussion :D
User avatar
UtahLlama
 
Posts: 205
Joined: 18 Sep 2012, 08:39
Location: The Grand Line

Re: Quark 2015 changing placed PDF's upon output

Postby nagarj » 07 Jan 2016, 16:14

Thanks, UtahLlama!

Using EPS files instead of PDF files helps, but several of my test PDF's still output incorrectly. So by itself that's no solution to this awful Quark bug.

We only had occasional output errors with placed PDF's in Quark 9. Incidence of trouble in Quark 2015 is, for us, far higher.

Even if all that font corruption didn't happen, it's very unnerving to see Quark radically changing the structure of the placed PDF's, even when Quark is told to pass through all transparency natively. Whey in the world is Quark doing *anything* to the structure of those placed files? That's always dangerous, as this problem shows.

Quark tech support has reproduced the issue and has sent my test files to their engineering department for analysis. I'm still waiting to hear back from them. I hope they identify the problem and issue an update to fix it very quickly. To us, this problem is so bad it deserves an emergency update to prevent Quark 2015 from ruining more perfectly good files. I do not consider Quark 2015 suitable for professional work in its current state, at least if one is placing PDF artwork, an extremely common procedure these days of course.

Thanks again.

Bill
nagarj
 
Posts: 20
Joined: 24 Nov 2015, 15:26

Re: Quark 2015 changing placed PDF's upon output

Postby shaun » 08 Jan 2016, 07:40

Just for interest I opened your Q2015 test file on Yosemite on a MacBook. The pdfs, viewed in Preview, showed errors which did not show up in Acrobat 9. The Quark test file looked correct, apart from the Charles Hotel image - the Century Gothic was scrambled. I exported the file as pdf; the text in the Charles Hotel image showed up correctly when opened in Acrobat 9.

I may have missed something, but the acrobat file is at
http://www.fergusoncreations.co.uk/pick ... st.pdf.zip
for comparison.
shaun
 
Posts: 340
Joined: 14 Jan 2006, 13:12

Re: Quark 2015 changing placed PDF's upon output

Postby nagarj » 08 Jan 2016, 08:21

@ shaun

I wonder what's different about your system configuration that allowed you to output the Charles artwork correctly from Quark 2015. Are you sure you had Quark set for native transparency output? If you tell Quark to either flatten or ignore transparency it outputs the file correctly, as my test files show.

I also see differences between Preview's and Acrobat's rendering of my test PDF's (and many others). For professional work I don't consider Preview accurate or useful, but it's interesting that it can behave so differently than Acrobat, even when Acrobat is set to ignore overprints.
nagarj
 
Posts: 20
Joined: 24 Nov 2015, 15:26

Re: Quark 2015 changing placed PDF's upon output

Postby shaun » 08 Jan 2016, 08:41

"I may have missed something" ...
Sorry, I did ... My pdf output was set to "flatten", not to native transparency output.
shaun
 
Posts: 340
Joined: 14 Jan 2006, 13:12

PreviousNext

Return to QuarkXPress 20xx: Output (Printing & PDF Export)

Who is online

Users browsing this forum: No registered users and 1 guest