Jump to content
You must now use your email address to sign in [click for more info] ×

Is 1bit image PDF export in Publisher possible now?


Recommended Posts

Simply stated: 1bit images are part of the core workflow in much of my work. I do not expect Photo to support these in R2 because the developers have unequivocally stated that Photo will never support a 1bit image mode. But that is fine: I can use PhotoLine and other software for that.

But it is ABSOLUTELY essential that Publisher leaves placed 1bit images alone and retains these in the PDF export. Publisher R1 is incapable of doing this.

Publisher finally adds book support and with the addition of 1bit image PDF export I can finally say InDesign farewell. But only if it actually works, and I cannot find this information anywhere in the new features list.

Would anyone be so kind to place the following 1bit image file in Publisher R2 and export to a PDF with these options:

  • downsample images turned OFF
  • allow jpeg compression turned OFF

And share the PDF with us here in this thread?

2017-10-01_inktober2017_swift_by-David-Revoy.tif

[image source: https://www.peppercarrot.com/en/viewer/sketchbook-src__2017-10-01_inktober2017_swift_by-David-Revoy.html]

Link to comment
Share on other sites

@tudor Many thanks for testing! 🙂

Oh my... :57_cry:

image.png.708cce2cae63fec2c5712ba276319d5e.png

It seems nothing has changed in R2. Which is a major personal disappointment, since 1bit image support is absolutely essential in the PDF output and must not be converted to a different image mode - it messes up the print, of course. These are commonly used in the publishing industry since the advent of desktop publishing.

Such a crying shame. Unless there is a new setting in the PDF export options that allows us to keep these untouched, to me Publisher is still unusable. So close! Books, notes, ... But as long as this is not fixed investing in the new version makes no sense to me, because I cannot use it.

This is what I had hoped to see instead:

image.png.0b1e92babac1f0679f2d58af1941a23d.png

Link to comment
Share on other sites

Tudor: It messed it pretty badly - I work in manga industry, and 1bit screentones are standart there - and if you send PDF to printer, but 1bit screentones are actually 8bit (grayscale) screentones, printed pages are full of moire, and thus, practicaly unusable...
Learnt that hard way, we have to shred whole issue of one book, and print it again.
 

Still don't understand why Affinity doesn't support 1bit images... they are standart in printing industry...

Edited by DanQ
Link to comment
Share on other sites

23 minutes ago, tudor said:

How exactly it messes up the print? It looks fine to me, a perfect 100% K PDF file.

It's not about just appearance. Not for myself, anyway.

As above, it will mess up screens. But, as your example is also output at 300dpi, that too is wrong. The file is at 599. 600 is a real minimum. But, I also, in the same file, will use full-color images that need output at different dpi. A professional application has setups to output different image types at different resolution just for these cases. As Affinity applications have a document dpi involved (dumb decision), I don't know if Serif would even be able to implement such a thing.

Your pdf is also larger KBs than need be because of the conversion (about 3 times larger). Image having an entire book with 100s of those images--aside from the printing issue.

Link to comment
Share on other sites

12 minutes ago, MikeW said:

Your pdf is also larger KBs than need be because of the conversion (about 3 times larger). Image having an entire book with 100s of those images--aside from the printing issue.

I just did a test: using InDesign I exported a PDF with no compression and no downsampling. The file was 1.9 MB, almost 4x bigger than the PDF created by Publisher.

Link to comment
Share on other sites

8 minutes ago, tudor said:

I just did a test: using InDesign I exported a PDF with no compression and no downsampling. The file was 1.9 MB, almost 4x bigger than the PDF created by Publisher.

You must be doing something wrong then: the above file placed in a blank document in InDesign 2023 and exported with printer's marks results in a 480kb file - which is still smaller than your test pdf with the incorrect converted 8bit file.

PS Ah, I see: you saved without compression. Choose the default compression option for monochrome images in the PDF export settings. The only reason why I asked for those settings in my original post is that I hoped it would prevent Publisher from converting the 1bit image.

Link to comment
Share on other sites

9 minutes ago, tudor said:

I just did a test: using InDesign I exported a PDF with no compression and no downsampling. The file was 1.9 MB, almost 4x bigger than the PDF created by Publisher.

Probably has an embedded profile. 

My output was about 180k.

Even so, final pdf output size is a small part of the issue. 

Link to comment
Share on other sites

1 hour ago, MikeW said:

Affinity applications have a document dpi involved (dumb decision)

I believe this was done mostly for the benefit of Photo, but the other apps inherit the resulting behaviors for compatibility.

It kind of makes sense for it to be there because of that, but having one present certainly shouldn't mean that every element of the document should be forced to conform to that setting unconditionally.

Link to comment
Share on other sites

3 minutes ago, fde101 said:

I believe this was done mostly for the benefit of Photo, but the other apps inherit the resulting behaviors for compatibility.

It kind of makes sense for it to be there because of that, but having one present certainly shouldn't mean that every element of the document should be forced to conform to that setting unconditionally.

Yeah, but...Publisher et al are aware of image/document dpi when placing or opening (more or less). The decision could have been made to not have a document dpi and make APub/AD better aware of such circumstances. Like other applications.

Link to comment
Share on other sites

6 minutes ago, MikeW said:

Yeah, but...Publisher et al are aware of image/document dpi when placing or opening (more or less). The decision could have been made to not have a document dpi and make APub/AD better aware of such circumstances. Like other applications.

This would fail to support the presence of pixel layers from the Photo/Designer personas.  The document DPI also makes sense when a layer is explicitly rasterized.

However, there is no reason why it should be applied to placed images which are in image layers (distinct from pixel layers).

What I am suggesting is that the document DPI should be present in support of pixel layers and rasterization, but should be ignored for image layers, which should retain their original format unless explicitly rasterized into a pixel layer.

I believe this is largely how it behaves now for the most part, but it could certainly be handled better when exporting.

Link to comment
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

Terms of Use | 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.