JOIN pages (opposite of split pages)  SOLVED

Forum for the PDF-XChange Editor - Free and Licensed Versions

Moderators: TrackerSupp-Daniel, Tracker Support, Paul - Tracker Supp, Vasyl-Tracker Dev Team, Chris - Tracker Supp, Sean - Tracker, Ivan - Tracker Software, Tracker Supp-Stefan

Post Reply
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

JOIN pages (opposite of split pages)

Post by DIV »

Hi, all.

I have PDF-XChange v 6.0. I would like to join pages in a PDF. Effectively this would be the same as to specify multiple pages per sheet when printing, except output/exported to a PDF instead of sending directly to a printer.
What I want is more-or-less the opposite of the existing "split page" functionality (e.g. https://www.pdf-xchange.com/forum3 ... 62&t=29216 ).

So far the only way I can see to do this is to use a third-party print-to-PDF tool, but that is causing other serious problems (either huge file size or low quality output).

Any tips?

Thanks,
David
User avatar
Will - Tracker Supp
Site Admin
Posts: 6815
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: JOIN pages (opposite of split pages)

Post by Will - Tracker Supp »

Hi David,

Thanks for the post - This isn't currently possible, but we are planning to add this into a future release.

Thanks,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Willy Van Nuffel
User
Posts: 2347
Joined: Wed Jan 18, 2006 12:10 pm

Re: JOIN pages (opposite of split pages)

Post by Willy Van Nuffel »

Hi Will and David,

Even though today it is not (yet) possible to join multiple pages directly 'within' PDF-XChange Editor V6, you can achieve this via PDF-XChange Lite V6 FREE printer. You do NOT need third party software for this.
https://www.pdf-xchange.com/produc ... fileid=574

By the way, this feature (printing "Multiple pages per sheet") is absolutely FREE, because I tried with the FREE (demo) version of the Editor combined with the FREE (demo) of Lite printer, and there are NO publicity stamps in the resulting PDF. Can we still ask for more ...

Best regards.
User avatar
Will - Tracker Supp
Site Admin
Posts: 6815
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: JOIN pages (opposite of split pages)

Post by Will - Tracker Supp »

Thanks Willy :)
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Re: JOIN pages (opposite of split pages)

Post by DIV »

Hello, Willy & Will.

I think I have figured out why this wasn't coming up as an option for me.
Even though I installed and paid for a licence for PDF-XChange Editor, I installed the portable version.
So, even though PDF-XChange Editor "Includes PDF-XChange Lite printer.", it wouldn't make sense for a portable version to install a printer driver to the operating system (I guess), so this never got installed on my computer.
I'm not really sure what the process could be to swap from the portable version of PDF-XChange Editor to the installed version of PDF-XChange Editor. I guess they would be completely independent. So in the meanwhile I'm just going to install PDF-XChange Lite.

By the way, Willy, as far as I can see PDF-XChange Lite is free without any limitation (i.e. not a "demo") for any non-commercial use; for commercial use it can be downloaded and used as on a trial basis for free, but for continued commercial use a (small) licence fee needs to be paid [via purchase of Editor, or Editor Plus, or PDF-Tools].
Also, the link you provided for download was to the x86 installer. There are also some other types of installer, including an x64 installer, from https://www.pdf-xchange.com/produc ... hange-lite .

Cheers,
David*

* But you can call me "William" if you prefer... ;-)


P.S. Although this seems to make sense in retrospect, I don't think it occurred to me at the time. From the product page (https://www.pdf-xchange.com/produc ... nge-editor) it is noted that one of the two portable installers omits OCR functionality, but it might be helpful to also indicate somewhere that the virtual printer is absent from both portable installers (if my supposition is correct).
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Workaround printing to Lite from Editor was unsuccessful

Post by DIV »

Hi, again.
In the intervening few minutes I've installed PDF-XChange Lite (from the x64 installer), and had a go at printing the document 4-per-page.
The original document was provided to me as a Word DOCX file of 45.4 MB size. I exported this from Word 2013 using the built-in functionality, which naturally is 1 page per sheet, producing a good-looking PDF file of 10.7 MB, claimed as PDF/A-compliant. This had wide margins, which I cropped in PDF-XChange Editor, resulting in another good-looking PDF file, of 10.8 MB size.
When I tried previously to print the cropped file from PDF-XChange Editor using PrimoPDF at 4-per-page, I got huge (~500 MB) files, and slightly wonky fonts; after drastically adjusting the settings I got a 51.4 MB file with appallingly rendered fonts.
Now using the newly installed Lite virtual printer from Editor, with default print settings except at 4-per-page, I get a 46.2 MB PDF, and somewhat wonky fonts.
For reference, the main font used in the document is Palatino Linotype (which I have installed on my computer, although fonts weren't embedded in the DOCX file), and attached is a zoomed-in screenshot illustrating the effect. I don't bother to include a 'control' for comparison, as the problem should be pretty evident; indeed, rendering of "s" is not even consistent (compare e.g. the serifs of the two instances shown).

My next step will be to try printing directly to Lite at 4-per-page from within Word. [Maybe I'll try some other combinations too.] However, even if this alternative happens to be successful (to be advised), I can't see why the above didn't work out.

Regards,
David
Attachments
20170625_PDFXChange-Lite_4-per-page_2.png
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Inconsistent results from various software combinations

Post by DIV »

Results:

PDF generated by Word; cropped by Editor; printed from Editor using PrimoPDF: (very) large file; wonky shaped fonts, black.
PDF generated by Word; cropped by Editor; printed from Editor using Lite: large file; wonky shaped fonts, black.
PDF generated by Word; printed from Editor using Lite: large file; wonky shaped fonts, black.
PDF generated by Word; printed from Editor using PrimoPDF: (very) large file; slightly wonky shaped fonts, black.
PDF generated by Word; printed from Adobe Reader 17 using Lite: very large file; (badly) bitmapped fonts [not embedded as in original], inconsistent black & grey mixture.*
PDF generated by Word; printed from Adobe Reader 17 using PrimoPDF: acceptable file size; well-shaped fonts [embedded as in original], uniformly changed from colour #000000 to #231f20.

* See "sms" image.

PDF printed from Word 2013 using PrimoPDF: small file size; well-shaped fonts [embedded], black.
PDF printed from Word 2013 using Lite: very small file size (9.7 MB); well-shaped fonts [embedded] but occasionally not perfectly aligned, black.**
PDF printed from Word 2013 using Lite with extended font info embedded: same as above.
PDF printed from Word 2013 using Lite with all of all fonts embedded: same as above, but large file.

** See "ry" image
Attachments
20170625_Word–Lite_4-per-page_1.png
20170625_Reader–Lite_4-per-page_1.png
Last edited by DIV on Sun Jun 25, 2017 5:58 am, edited 1 time in total.
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Sample files

Post by DIV »

Attached are:
  • PDF file generated by opening Word-generated PDF file within Editor and printing (pages 1–4) to Lite at 4-per-page, illustrating font issue.
  • First four pages of Word-generated PDF file (resaved only for uploading here).
  • NOT{First few pages of Word file (resaved only for uploading here).} [Cannot be uploaded to forum.]
Text and numbers were changed for privacy: no formatting or procedures were changed.

—DIV
Attachments
PhD_thesis_UnivMOD_TEST.Editor-Lite.pdf
(160.77 KiB) Downloaded 139 times
PhD_thesis_UnivMOD_pp1-4.pdf
(612.72 KiB) Downloaded 142 times
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17820
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: JOIN pages (opposite of split pages)

Post by Tracker Supp-Stefan »

Hello Div,

When you convert a file from Word to PDF (whether with the built in features of Word, or using a virtual pritner) - this will use the actual fonts and include them as text in the file.
While when you use the Editor to "reprint" the PDF file - the Editor will normally sent not fonts info but rather vector objects to the printer - this ensures consistent printing on paper, but when you reprint a PDF - will give the results that you observed.
Please try the setting from the attached file - and the Editor should then only send as curves fonts that are embedded in the document, and all others will be send as actual text/font info to the printer. So if your original file does not have any fonts embedded - they should still "reprint" fine with that option.

The default behaviour is what it is - as most of the time you do not need to reprint a PDF file back to PDF as you can do pretty much all manipulations directly inside the existing file using the tools the Editor offers, and you mostly only need to print to paper, and with the myriad of printers out there - the current approach we use guarantees much more consistent results (and most modern browsers do the same - try printing a web page through Chrome - and you will get curves instead of fonts).

Regards,
Stefan
Attachments
print_settings.png
Willy Van Nuffel
User
Posts: 2347
Joined: Wed Jan 18, 2006 12:10 pm

Re: JOIN pages (opposite of split pages)

Post by Willy Van Nuffel »

Hello everyone,

I have tried the above settings to print multiple pages from a PDF to single pages in a new PDF (via Outline for Embedded Fonts), but it seems like the text from the original PDF still prints like individual shapes in the new PDF, not text. So, it can not be used for further editing.

So, I believe the best solution to print multiple pages from a Word document to single pages in a PDF, is via Word itself.
This by specifying "x Pages Per Sheet" in the Microsoft Word "Print" dialog box and selecting "PDF-XChange Lite V6" as destination printer.

David (or alias William), can you please check if this works for you too, and give us a little reply.

Best regards.
User avatar
Will - Tracker Supp
Site Admin
Posts: 6815
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: JOIN pages (opposite of split pages)

Post by Will - Tracker Supp »

Hi Willy,

Thanks for that - One thing to note: If Outline For Embedded Fonts is enabled, this will print text as curves instead of actual text, so it should be set to Auto if text information is desired.

Thanks,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
Willy Van Nuffel
User
Posts: 2347
Joined: Wed Jan 18, 2006 12:10 pm

Re: JOIN pages (opposite of split pages)

Post by Willy Van Nuffel »

Thanks Will for making this clear.

I have got another try, and yes indeed, when the Text Rendering Mode is set to Auto, the text in the original PDF is still text in the resulting PDF, when multiple pages per sheet are printed.

This is good to know, because at the end myself I was going to mix options in the wrong manner.
User avatar
Will - Tracker Supp
Site Admin
Posts: 6815
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: JOIN pages (opposite of split pages)

Post by Will - Tracker Supp »

:D
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Printing multiple pages per sheet direct from Word

Post by DIV »

Hi, Willy.
You suggested:
I believe the best solution to print multiple pages from a Word document to single pages in a PDF, is via Word itself.
This by specifying "x Pages Per Sheet" in the Microsoft Word "Print" dialog box and selecting "PDF-XChange Lite V6" as destination printer.

This indeed would make some sort of sense, and I think it is akin to what I ended up doing (which I now need to try hard to recall, in case I need to replicate it in my current task).

The main wrinkle in this is that in order to squeeze four pages per sheet and still have the text vaguely readable, I wanted to strip out (e.g. 'crop') the ~30mm margins down to say 1mm. Of course, I would never do this for final publication; this is for my own (proof)reading/(copy)editing ends.
As you would no doubt realise, there is no convenient way to remove whitespace margins in Word — it involves tandem operations of reducing the margin widths and making corresponding reductions in the page dimensions, without a guarantee of exactly the same text flow/layout and pagination as in the original. That inconvenience was at the core of my desire to be able to "join" pages within PDF-XChange Editor.

Another issue that came up is the 'encoding' of the graphic elements present in the original Word document. See attachment for example. The different print engines seem to behave rather differently — at least, without investigating every possible combination of settings.

—David (a.k.a. William)
Attachments
Screenshots_RevA.pdf
(244.26 KiB) Downloaded 144 times
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Text rendering mode

Post by DIV »

Hello, all.

First up I should say that I totally accept Stefan's point that the default settings are designed for the most robust performance in the most common usage patterns (i.e. printing to a an actual printer, rather than printing to PDF).
I did look through the various (numerous!) settings under Preferences, and I had also had a bit of a look at the print options from within Editor, although (from memory) my consideration of the Advanced Print Options may have been limited to consideration of the output resolution settings.

Having said that, I was/am somewhat confused by the Text Rendering Mode.
This was already set to "Outline for Embedded Fonts" in my application. I couldn't say for sure whether I'd changed it at some time and forgotten, or whether it was the application's default setting.

Anyway, I tested out all five Text Rendering Mode settings, each for two (related) PDF files*, which I opened in Editor and printed-to-file using Lite. The same behaviour was obtained for both 'source' files.
Auto:
  • Text is rendered as good-looking fonts.
  • The embedded 'fonts' shown under Document Properties are all ad hoc assemblies of characters named as e.g. "XF202E.tmp", and there are over fifty of these font-fragments.
  • Select-copy-paste from the resultant PDF yields garbled encoding (e.g. "counterclockwise" becomes "Œ˜ž—Ž›Œ•˜Œ” ’œŽ"; "modification" becomes "˜™’–’œŠ’˜—" [there are Unicode characters that are not showing here]).
  • The letter "o" is, bizarrely, missing from one-only of the fonts (namely "Calibri").
Bitmap Always and Bitmap for Embedded Fonts and Outline Always and Outline for Embedded Fonts:
  • All text is rendered in what I had called "wonky" forms, which we now know is called rendering using "curves".
  • There are no embedded fonts whatsoever.
  • It is not possible to select text (because it is really a series of graphics now).
  • All characters are shown (nothing missing).
It was a little surprising that nothing that looked like bitmapping of fonts appeared, despite the setting(s) that seemed to suggest that this would occur.

Would the "Font Embedding Options" under "Print > Properties" in Lite have affected any of the above?

—David (a.k.a. William)

* One exported as PDF/A-1a from Word, the other a cropped version of this created [as I recall] from PDF-XChange Editor. There are 22 fonts embedded in these files, all intuitively named as in e.g. "Arial MT (Embedded Subset)".
Last edited by DIV on Sat Jul 15, 2017 12:19 pm, edited 2 times in total.
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Summary of motivation

Post by DIV »

Going back to my original post, by my non-expert thinking the advantages of doing the 'JOIN' operation wholly within Editor would be not just the convenience to the user, but also, by avoiding converting from PDF to (say) PostScript and then back into PDF, it avoids many opportunities for problems in 'encoding'.
—DIV
Willy Van Nuffel
User
Posts: 2347
Joined: Wed Jan 18, 2006 12:10 pm

Re: JOIN pages (opposite of split pages)  SOLVED

Post by Willy Van Nuffel »

The most easy solution would indeed be having a "join multiple pages to single page" feature in PDF-XChange Editor.

Currently, you will have to work to a solution where you have no more 'embedded' fonts in the resulting PDF that comes from Word, and because you like to crop the 30 mm margins, you will have to print your Word document via Lite printer, single Word-pages to single PDF-pages, as a first step.

You can achieve this as follows:
1) in the PDF-XChange Lite printer, via the Fonts option, add all the fonts that you are using in your Word document to the "Never embed fonts" list
2) if you see that there are still embedded fonts in the resulting PDF, you should search for what text they are used, and then select an other font for it in your Word document

Once you have no more embedded fonts in your resulting PDF, you can then use it for cropping and joining to a final PDF, as the next steps.
When printing to PDF-XChange Lite via PDF-XChange Editor, take care to set the "Text Rendering Mode" to "Auto".
:-)

I hope this helps?
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Trying out the suggested workaround

Post by DIV »

Hi, Willy.
Thanks for the suggestion.
Unfortunately, however, I haven't been able to implement it. In short this is because I cannot seem to generate a file without embedded fonts. *CORRECTION* I was able to duplicate your procedure, but I misconstrued the result (I incorrectly thought the fonts were still embedded, regardless of the settings used).
I tried the following:
  • Print document from Word using Lite with no font embedding requested, but rather prohibitions on embedding all fonts used in the Word document.
  • Print document from Word using Lite and specifying complete embedding of all fonts used, including protected fonts (whatever they are) and extended font information (whatever that is).
  • Export to PDF using Word's built-in engine, with PDF/A compliance; subsequently request removal of all embedded fonts using Editor (File > Save as Optimized ... > Fonts > unembed manually).
The first two documents look the same as each other, and each of them (despite the differing virtual-print settings) has the same number of embedded *CORRECTION* listed virtual-fonts. I say "virtual-fonts", because the number of "fonts" shown in Document Properties for each of these is 200 (yes, two hundred!). The look is extremely close to the original document (and also the Word-exported PDF), with the exception of slight discrepancies in character alignment as illustrated with the "ry" sample image in a previous post on this topic. The only obvious difference between the two outputs is the file size: 9.23 MB versus 18.1 MB, respectively. *CORRECTION* However, looking more closely at the font listing in Document Properties, only the second PDF indicates that each of the 'fonts' is an "Embedded Subset"; apparently in the first PDF the listing only indicates that that 'style' is 'marked' in the document.

The last document still has 22 fonts listed in Document Properties, even though supposedly they should have all been stripped out. *CORRECTION* The main difference is that in the originally exported PDF all fonts were shown as "Embedded Subset", whereas in the listing for the 'optimised' PDF most fonts were apparently not embedded, although there were seven fonts that were still shown as "Embedded Subset". The only *CORRECTION* other difference in the listing, compared to the originally exported PDF, is that (unexpectedly) Editor shows two additional parameters for each embedded font in the 'optimised' document, namely "Actual Font" and "Actual Font Type" (e.g. for the ArialMT font these parameters are respectively "Arial" and "TrueType"). However, the appearance of the displayed text is dramatically altered in several PDF viewers other than Editor. If I open this 'optimised' PDF in any of Adobe Acrobat 7.0, Adobe Acrobat Reader DC 2017, or Foxit PhantomPDF 7.2, then almost all of the characters are displayed in a font style never used in the original document that is reminiscent of the Dunhill brand (thin, tall, sans serif). IrfanView 4.44 also shows most of the text in the 'optimised' PDF as sans serif (albeit fatter than in the other viewers); I wouldn't rely on this for rendering PDF files, but it does at least correctly display the relevant text in the original PDF as serif. In Editor and in Microsoft Reader 6.4.9926.18471 x64 the text in this same 'optimised' PDF all looks like it did in the original, which I cannot explain.

—David
Last edited by DIV on Tue Jul 18, 2017 1:55 pm, edited 2 times in total.
Timur Born
User
Posts: 874
Joined: Tue Jun 26, 2012 1:50 pm

Re: JOIN pages (opposite of split pages)

Post by Timur Born »

Embedding fonts isn't X-Change's strong(est) point, unfortunately. Unless you own Adobe Acrobat your best options for this would be Primo, FreePDF or any other good implementation of Ghostscript. As you have experienced there are cases were X-Change will embed fonts, but not as their original text characters, which fits optically, but only if you don't plan to ever edit the document or use text search functionality.

So currently my only solution for good reprinting of PDF files is to print from Acrobat Reader (better full version, because of color-control) to a Ghostscript based printer (Primo works very good). Unfortunately this leaves my complete X-Change package without a job to do. ;)
Willy Van Nuffel
User
Posts: 2347
Joined: Wed Jan 18, 2006 12:10 pm

Re: JOIN pages (opposite of split pages)

Post by Willy Van Nuffel »

Hello,

For a short test, I have made a Word document with a few different fonts in regular, italic and bold.

Then I printed the document with the Lite printer, and in its "Font" settings I inserted the fonts (that I have used in the Word document) into the list of "Never Embed Fonts" (making sure to also activate the concerning check box).

The resulting PDF is also included (no one of the fonts has been embedded).

I wonder if you can obtain the same results and if you can continue the same way, when you should add specific fonts in my document that you are using in your document.

Best regards.
Attachments
Test with different fonts.zip
(17.67 KiB) Downloaded 112 times
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Font embedding (or lack of) misinterpreted by me previously

Post by DIV »

Hi, Willy.

SHORT ANSWER: I might, perhaps, be able to devise a simple test case that works as you describe, but with the real DOCX file, it fails.
*CORRECTION* it seems that I was misinterpreting the "Fonts Used" information in Document Properties!

After downloading your sample PDF which you noted didn't have embedded fonts, I realised that the 18 fonts listed in Document Properties that I had otherwise thought were embedded, must merely be 'marked' as styles in the document without the fonts actually being embedded.

The procedure you describe appears to be the same as you had suggested previously, and was what I had already tested in the first dot-point of my earlier post. This created a PDF with 200 'fonts' embedded *CORRECTION* defined as marked styles in the document, and file size of 9.2 MB.

Before I realised this, I tried again (twice) to see if I could replicate my own earlier result, and attach a screenshot of the exact settings used. As you can see, I specified a bunch of fonts that were present in the Word document (and also embedded or marked as styles in the typical PDF files exported or printed).

In the first of these repeats I obtained a PDF that still contained 200 fonts. These were marked as "Embedded Subset" [see attachment]. Which is weird, because the file size of this PDF was 18.1 MB, which I would associate with embedding complete fonts rather than subsets.
This made me think that perhaps I had accidentally not clicked "OK" to confirm the virtual-print settings that I thought I'd chosen in Lite. When I went back to Word, the above concern was galvanised as the virtual-print settings did not have the tick next to "Never Embed Fonts".

I tried once more, and this time I set the settings (as shown in the attachment), carefully clicked "OK", closed the dialogue, and reopened the dialogue to confirm that the settings had indeed 'stuck' (which they had).
The PDF generated from this was (practically) the same as in my earlier post: contains 200 'fonts' *CORRECTION* includes 200 marked 'font' styles [see other attachment], and file size of 9.2 MB (but 10 bytes [yes, bytes] bigger than the earlier-generated file, and the "fc" command in a command prompt shows a few differences in the encoding within these two files).

—David
Attachments
PhD_thesis_0707.Word-Lite.noFonts3.300dpi.settings.png
PhD_thesis_0707.Word-Lite.noFonts3.300dpi.fonts.png
PhD_thesis_0707.Word-Lite.noFonts2.300dpi.fonts.png
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Re: JOIN pages (opposite of split pages)

Post by DIV »

Timur Born wrote:So currently my only solution for good reprinting of PDF files is to print from Acrobat Reader (better full version, because of color-control) to a Ghostscript based printer (Primo works very good).
Hi, Timur.
Thanks for sharing your experience and recommendation. It is kind of consistent with my simplistic* testing in post #7 above. Other than the peculiar text-colour change that I noticed, the results seemed OK.
The biggest problem I've had recently with PrimoPDF is generating excessively large file sizes (somewhere maybe the resolution is set too high). Besides that, obviously PrimoPDF has relatively few customisation options. But those are perhaps topics for a different forum!
—David

* I say "simplistic" because at that time I was not carefully heeding the Text Rendering Mode discussed in post #15 above.
Willy Van Nuffel
User
Posts: 2347
Joined: Wed Jan 18, 2006 12:10 pm

Re: JOIN pages (opposite of split pages)

Post by Willy Van Nuffel »

Thanks David for your answer.

The problem seems to be rather complicated, probably because of specific fonts and/or characters used in your Word document.

I am afraid that without an example Word document from your side, it will not be possible (for me) to reproduce the problem.
If it goes about confident content, you can always send it to support@pdf-xchange.com, for further investigation - instead of posting it on this forum.

Best regards.
Timur Born
User
Posts: 874
Joined: Tue Jun 26, 2012 1:50 pm

Re: JOIN pages (opposite of split pages)

Post by Timur Born »

DIV² wrote: Other than the peculiar text-colour change that I noticed, the results seemed OK.
The free version of reader does not offer full color-management, but there are some options you need to check.

In the Print dialog click on the Advanced button. Disable "Let printer determine colors, "Enable "Preserve Black", disable "Treat grays as K-only grays" and "Preserve CMYK Primaries". If this does not work then try to enable "Let printer determine colors", which in turn grays out all the other options.

Usually Primo compresses PDF file (which FreePDF does not seem to do), so files should not be too large, but its compression is weaker than X-Change's. Can you upload a sample file to test X-Change vs. Primo file sizes?
Last edited by Timur Born on Mon Jul 17, 2017 9:16 am, edited 2 times in total.
Timur Born
User
Posts: 874
Joined: Tue Jun 26, 2012 1:50 pm

Re: JOIN pages (opposite of split pages)

Post by Timur Born »

Curiously FreePDF turned the text into bitmap graphics in this test. Never had that happen before. I even used it as my reference until now. But since it's not being supported anymore, Primo will be my future reference for Ghostscript based PDF printers. Here is a comparison of X-Change Standard with and without text-compression vs. Primo (prepress template). All printed at 2400 dpi. Keep in mind that X-Change (both printer and Editor) renders fonts slightly differently to Acrobat and Ghostscript, like usually a bit larger in pixel height.

But first of all, I found out under which circumstance Primo changes black font color to a dark reddish hue gray: If "Let printer determine colors" is disabled in Acrobat Reader and any Primo template other than "Screen" or "EBook" is used then black text color is changed. If "Let printer determine colors" is enabled or if the "Screen" or "EBook" template is used then black font remains black.
Attachments
PhD_thesis_UnivMOD_pp1-4_xpst_textcomp.pdf
(85.94 KiB) Downloaded 114 times
PhD_thesis_UnivMOD_pp1-4_xpst_nocomp.pdf
(171.36 KiB) Downloaded 107 times
PhD_thesis_UnivMOD_pp1-4_primo_preprint_let.pdf
(110.03 KiB) Downloaded 113 times
PhD_thesis_UnivMOD_pp1-4_primo_preprint.pdf
(110.83 KiB) Downloaded 120 times
Timur Born
User
Posts: 874
Joined: Tue Jun 26, 2012 1:50 pm

Re: JOIN pages (opposite of split pages)

Post by Timur Born »

One thing to underline: In the end it all comes down to the point where X-Change needs to learn how to properly embed fonts by using real characters. Ghostsript can do it, Adobe can do it, X-Change should do it as well.
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Font embedding : multiple subsets versus merged subsets.

Post by DIV »

Hi, Willy.
In relation to the surprisingly large number of fonts embedded (or merely 'listed'), I think I have a partial answer, but I feel that this issue is getting a bit far off the original focus of the present topic, so I have created a new post, "Font embedding : multiple subsets versus merged subsets", where that can be explored in further detail.
—David
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

comparison of X-Change Standard with and without text-compression vs. Primo (prepress template)

Post by DIV »

Timur Born wrote:Here is a comparison of X-Change Standard with and without text-compression vs. Primo (prepress template). [...]
But first of all, I found out under which circumstance Primo changes black font color to a dark reddish hue gray: [...]
Hey, Timur, thanks for your great detective work.
It is interesting to look at the breakdown of data content in the four files you uploaded (from "Audit space usage" in Editor):
  • PhD_thesis_UnivMOD_pp1-4_xpst_nocomp.pdf
    (171.36 KiB)
    Content (1): 113 KiB. Fonts (12): 58 KiB. Overhead (4): 1 KiB.
  • PhD_thesis_UnivMOD_pp1-4_xpst_textcomp.pdf
    (85.94 KiB)
    Content (1): 27 KiB. Fonts (12): 58 KiB. Overhead (4): 1 KiB.
  • PhD_thesis_UnivMOD_pp1-4_primo_preprint.pdf — [this renders text as colour #333333]
    (110.83 KiB)
    Content (2): 3 KiB. Fonts (23): 103 KiB. Overhead (5): 3 KiB.
  • PhD_thesis_UnivMOD_pp1-4_primo_preprint_let.pdf
    (110.03 KiB)
    Content (2): 3 KiB. Fonts (23): 103 KiB. Overhead (5): 3 KiB.
So Primo is somehow condensing the content stream quite a bit more than even the compressed version of PDF-XChange Standard (which I don't have).
On the other hand, somehow the data consumption for saving font information here is less for the XChange-generated files. I don't really understand the number of 'fonts' indicated under "Audit space usage" which are shown above; they don't match the values shown under Document Properties, which are respectively 4, 4, 7 and 7.
When I look at the original Word document, I can confirm that these pages did contain text set in Palatino, Garamond (submission statement), Calibri Light, Calibri italic, and Times New Roman (the fractions). I can't find any visible text set in Calibri roman, but there are several 'return' characters set in this font. So by my count the XChange-generated files have an insufficient number of fonts judging by the Document Properties data, and the Primo-generated files have an excess number of fonts on the same basis (this is obviously because Palatino is listed twice in those files).

The PrimoPDF colour changing is quite weird. In Adobe Reader I did not have "Let printer determine colors" ticked, and in PrimoPDF I have been using "Custom", so I managed to find an unlucky pairing. I appreciate your advice on this. (It's also odd that the file you made where the colour was changed seems to have a different hue to mine ...but that's definitely a detail that we don't need to discuss in further detail on this forum.)

Thanks,
David

P.S. I suppose either you have used a more appropriate "Auto" setting for Text Rendering Mode in Standard, or else Standard does this as a matter of course. (Not sure, as I only have Editor and Lite.)

P.P.S. In contrast to your comment about Standard, I am not sure that there is any option to turn on or off the text-stream compression in Editor or Lite. The closest I saw in the manual was an option to "Use Flate to encode streams that are not encoded" when (re)saving an 'optimised' version of an existing PDF.
Last edited by DIV on Tue Jul 18, 2017 1:36 am, edited 1 time in total.
Timur Born
User
Posts: 874
Joined: Tue Jun 26, 2012 1:50 pm

Re: JOIN pages (opposite of split pages)

Post by Timur Born »

Primo likely changes colors based on your current display profile, or rather Adobe Reader does. I don't use a sRGB profile, but a large color space one. Color management is a whole other problem area where XP might struggle. Adobe Acrobat (full) offer more color management options for printing than the free Reader.
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Colour management

Post by DIV »

Hi, Timur, you're probably right about the display profile. "sRGB" seems to be a common default, and I imagine it's probably what my applications were using.
—David
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Willy's solution

Post by DIV »

Hi, Willy,
after I finally figured out the interpretation of the listings of fonts under Document Properties, I have gotten around to following up on your suggestion to not embed fonts in the PDF used to build a four-per-page 'joined' PDF.
By the by, I might say that this suggestion seemed against my intuition ...but nevertheless, it seems to work so far. Even if I don't understand the logic.
(Timur, I also value your suggestions for 'workarounds'. Unfortunately I can only mark one contribution as a "solution".)

Here is what I have now:
  1. Starting with Word export.
    1. From Word export PDF as PDF/A. 12.6 MB. Sensible number of font subsets are embedded, with meaningful names ('Calibri-Italic', etc.). Text can be searched and copied.
    2. Crop margins of resulting PDF in Editor, discarding cropped content. 12.5 MB. Sensible number of font subsets are still embedded, with meaningful names. Text can be searched and copied.
    3. Print resulting PDF from Editor, with Text Rendering Mode set to "Auto", to Lite, with Fonts all to be embedded as subsets and Layout as 4 pages per sheet. 17.9 MB. Excessive number of font subsets are embedded, with temporary names ('X@Fhhhh.tmp'). Text cannot be searched or copied. The letter "o" is missing from any text set in a Calibri/Calibri-Light family font.
    So this doesn't work.
  2. Starting with Lite print with embedded fonts.
    1. From Word print document to PDF using Lite, with all used Fonts to be embedded as subsets. 18.1 MB. Excessive number of font subsets are embedded, with meaningful names ('Calibri-Italic', etc.). Text can be searched and copied.
    2. Crop margins of resulting PDF in Editor, discarding cropped content. Excessive number of font subsets are embedded, with meaningful names. 18.1 MB. Text can be searched and copied.
    3. Print resulting PDF from Editor, with Text Rendering Mode set to "Auto", to Lite, with Fonts all to be embedded as subsets and Layout as 4 pages per sheet. 16.4 MB. Excessive number of font subsets are embedded, with temporary names ('X@Fhhhh.tmp'). Text cannot be searched or copied. The letter "o" is missing from any text set in a Calibri/Calibri-Light family font.
    So this doesn't work.
  3. Starting with Lite print without embedded fonts. (Willy's suggestion.)
    1. From Word print document to PDF using Lite, with no Fonts to be embedded as subsets. 9.2 MB. Sensible number of font subsets are listed (but not embedded), with meaningful names. Text can be searched and copied.
    2. Crop margins of resulting PDF in Editor, discarding cropped content. 9.2 MB. Sensible number of font subsets are listed (but not embedded), with meaningful names. Text can be searched and copied.
    3. Print resulting PDF from Editor, with Text Rendering Mode set to "Auto", to Lite, with Fonts all to be embedded as subsets and Layout as 4 pages per sheet. 21.8 MB. Excessive number of font subsets are embedded, with meaningful names ('Calibri-Italic', etc.). Text can be searched and copied. All letters are shown correctly.
    So this works. Although the file size appears to be somewhat inflated by the presence of some redundant font subset data (replication of the necessary font subset data).
Possibly this workflow might not be so successful if I didn't have the relevant fonts also installed onto my system (given that I am not the author of the original Word document).

All documents look similar except that the letter "o" is missing from any Calibri/Calibri-Light family font in documents 1c and 2c.
There are slight discrepancies in the 'microscopic' alignment of letters, as in the "ry" image uploaded previously.
I also noticed slight discrepancies in the relative heights of "z" and "i" in text set in Garamond font, but I don't have a 'Gold Standard' to know which of them is 'correct', so I can't draw a firm conclusion about that!

I haven't yet physically printed any of these.

Regards,
David

P.S. For reference, the Word document is 35.8 MB in size, mostly due to the graphics that are present.
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

PrimoPDF

Post by DIV »

Just for comparison, perhaps for Timur's interest, I also generated a four-per-page PDF using PrimoPDF.
I opened the PDF obtained from step 1b (see my previous post) in Adobe Reader, with "Let printer determine colors" enabled, and printed this to PrimoPDF, with PostScript resolution set to 300dpi, output intent set to "Print", and PDF resolution set to either 100dpi or 300dpi. (Yes, there are two different places to specify resolution in PrimoPDF.)
Resulting PDF: 9.9 MB. Sensible number of font subsets are embedded, with meaningful names ('Calibri-Italic', etc.). Text can be searched and copied. All letters are shown correctly.
So this works. Although the resolution/quality of the graphics in the PDF obtained seems to be slightly lower than in the PDF file obtained from step 3c (see my previous post). The "PDF resolution" didn't affect file size, and by inference couldn't affect image quality.

Also, following Timur's suggestion, the text is correctly rendered as black with these settings.

—David
Willy Van Nuffel
User
Posts: 2347
Joined: Wed Jan 18, 2006 12:10 pm

Re: JOIN pages (opposite of split pages)

Post by Willy Van Nuffel »

Thanks David for sharing the results of your tests.

Probably the difference in file size between Lite and PrimoPDF is due to the fact that there are no options for down-sampling, nor for compression (in Lite). Besides this, let us hope that Tracker Software is prepared to further fine-tune their Lite printer, by incorporating optimization and/or fixing some problems with font embedding for particular fonts (like you say, for Calibri).

On the other hand, in all cases where there is no reason to incorporate fonts in the resulting PDF, I would not do that.
This will avoid large file sizes and also printing problems (incorrect spacing between characters, missing characters, ...).
But yes, like you already know in the meantime, the same set of fonts - as those used in the original file - must be available on the other PC.

Best regards.
Timur Born
User
Posts: 874
Joined: Tue Jun 26, 2012 1:50 pm

Re: JOIN pages (opposite of split pages)

Post by Timur Born »

If I remember correctly then Lite uses image resampling and image compression, both of which are enabled by default in Standard as well, but can be changed there. I don't know which compression strength is used by lite (75% JPEG default in Standard).

PDF resolution affects letter details, spacing, maybe kerning and generally (sub)pixel-correct placement of letters and images on the page. For text it can be set to 600 dpi and higher without so much of a difference for file size, but it may lead to longer printing times. For images you might want to re-sample/downsize if you are using high DPI settings.
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

Wrap-up

Post by DIV »

Hi, Timur.
What you say about the resolution affecting the "microscopic" (or "subpixel") alignment/kerning of letters sounds plausible.
(BTW, the differences in relative heights of "z" and "i" in text set in Garamond font is actually something else: the difference in heights between various PDF documents is comparable to the stroke width. However, even if I compare the PDF exported 'directly' from Word with the text displayed in a magnified 'page layout' mode in Word itself, the sizes are not consistent, so I don't know which one is 'correct'. Admittedly, that's a pretty minor issue, but I just found it surprising.)

Hi, Willy:
I should probably have said also a louder "thank-you" to you for your suggestion which was always correct, even though it took me a long time to implement it!
Regarding the image compression/downsampling options, we know from other posts that Tracker Software considers Lite to be a *ahem* 'light' version of the printer functionality available in PDF-XChange Standard. So that would be a business decision for them how many extra features to include in Lite. (On the other hand, there should ideally not be any bugs in either of them.)
BTW: Would you be able to explain why printing a PDF with embedded fonts (onto paper!) could produce a different result to printing an equivalent PDF with the fonts installed on the system but not embedded? Is this what you were saying? I would have expected — at least theoretically — that the results of these should be identical.

Regards,
David
Willy Van Nuffel
User
Posts: 2347
Joined: Wed Jan 18, 2006 12:10 pm

Re: JOIN pages (opposite of split pages)

Post by Willy Van Nuffel »

Hello,

1) Done with pleasure. It is not always easy to clearly (and also shortly) explain why a specific advise is being given.
Mostly there are a few good reasons for it.

2) I agree that Lite is indeed a light (and also a slightly "different") version of the PDF-XChange Standard printer, and that - even though its settings are limited - it should be preferable for its users (and also for Tracker Software) that it should be bug free.

3) I am not a specialist in PDF creation, but I think that even when "Embed Extended Font/Character Info" has been checked in the PDF printer driver, the font itself is still NOT yet completely incorporated in the PDF file. So, when the printer engine (of the real printer) can completely rely to the installed font in the operating system itself, you can be quasi 100% sure that is has all the needed information to print it equal to the original.

4) In Microsoft Word (2010) there is still a parameter (via File > Options > Advanced, at "Display"-settings), that goes about "Optimize character positioning rather for layout than for readability" that plays a role in the character spacing (kerning). I do not have an immediate example for this, but you should be able to see a difference for particular character pairs, when this option is ON or OFF.

Best regards.
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17820
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: JOIN pages (opposite of split pages)

Post by Tracker Supp-Stefan »

Hi All,

Wow that has become one serious discussion!
I just want to add a few things that will hopefully clarify some of the points discussed.

The Editor's print feature is mainly focused on printing to paper - and our aim is to make 'reprinting' of a file obsolete and no longer needed - by providing tools to perform any operation for which a reprint is necessary an alternative tool directly in the Editor. It turns out that this join operation is one of the last remaining that can be done with printing and not with any other tools :)

When a font is used - part of the information is the "glyphs" that are needed so that the letters can be displayed/printed. The Extended information is needed for e.g. text extraction - so that you can copy this text and paste it in notepad. If the Extended information is not included - the text is still text (and not different vector objects) and will display smoothly and correctly, but you won't be able to copy it.

When the Editor prints - for any font that is not embedded - it will search for the font in the C:\Windows\Fonts folder - and use that - passing the font information directly from there to the printer.
When a font is embedded - it will normally print it as curves, and with the "Auto" option - it will try to generate a new font (one of those with the 'random' names you've observed) - and pass that as a font to the printer. It will contain all the glyph information - so the newly printed text will still be text - but it will lack the Extended information needed for text extraction. I am not sure if it can be changed in the future - and if it is very complicated operation - whether we will be able to allocate the resources needed. (My thought here being that if the "Join pages" operation is easier to implement - it might not be worth spending more time to improve printing of embedded fonts to send the extended character info to the printer for the only case where it's relevant - reprinting back to PDF).

The Lite printing driver's image settings are the same as what you can see as the defaults in the Standard driver.
It uses a slightly different printing engine than the Standard - and I will now ask a colleague that works on these specific driver font issues to look at the missing letter o in the Calibri font discussed above.

Regards,
Stefan
Timur Born
User
Posts: 874
Joined: Tue Jun 26, 2012 1:50 pm

Re: JOIN pages (opposite of split pages)

Post by Timur Born »

Direct reply (disagreement) to what Stefan wrote about "only use case", but still somewhat off-topic in this thread, so posted elsewhere: ;)

https://www.pdf-xchange.com/forum3 ... 48#p115348
Last edited by Timur Born on Mon Jul 24, 2017 1:55 pm, edited 1 time in total.
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17820
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: JOIN pages (opposite of split pages)

Post by Tracker Supp-Stefan »

Thanks Timur,

Lets continue the conversation in the other thread!

Cheers,
Stefan
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

The case of the missing "o" (in Calibri)

Post by DIV »

Hi, Stefan.
Thanks for the extended explanation of how the printing works.
I was especially interested to learn how the "Extended information" affects the resulting output. It is not at all what I had guessed. (I had incorrectly made a vague guess that it related to 'advanced' OpenType features, or something like "font hinting".) I can understand if software developers could even get disappointed occasionally when users don't read whatever helpful information is in the manual, and actually I am someone who does sometimes read manuals — but not always. My suggestion would be to make the option clearer in the dialogue box by amending from the current "Embed Extended Font/Character Info" to something like "Embed Extended Font/Character Info (for copying text)". That way the meaning of the option becomes more obvious.

If you or your colleagues are interested in investigating 'The case of the missing "o" (in Calibri)', then possibly the attached sample will be of some use.
This is obtained from one of the original PDF files that spurred my remarks. The only differences from the original file are that, within Editor I have: (i) deleted all of the pages/sheets except for two, and (ii) redacted most of the text, because I'm not the author of the document.
You can see that in this document:
  • only lowercase "o" in Calibri / Calibri Light is missing
  • uppercase "O" in Calibri / Calibri Light did not show any obvious problems
  • lowercase "o" in the other fonts did not show any obvious problems
  • no other letters showed any obvious problems
Thanks again to Willy & Timur for further input.

Regards,
David
Attachments
PhD_thesis_0707.Word-Lite.allFonts.300dpi.cropped_by4.samplePage.pdf
(162.96 KiB) Downloaded 109 times
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17820
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: JOIN pages (opposite of split pages)

Post by Tracker Supp-Stefan »

Thanks David,

I've asked a colleague from the dev team to look at this sample, and we will post back here once we've had a chance to look at it.

Regards,
Stefan
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17820
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: JOIN pages (opposite of split pages)

Post by Tracker Supp-Stefan »

Hi David,

The Lite printing driver first gets the information as XPS file, and then converts it to PDF. The problem seems to be with the conversion from XPS to PDF - as if you "print" the file from the Editor to an XPS printer - the letter is there and visible. If you then drag and drop the same xps file in the Editor - the letters disappear. So the issue is with the conversion and it affects both the Editor and the Lite printing driver.
I've created a ticket in our internal system for this:
#3985: Editor + Lite: Issue with converting from XPS to PDF - missing letters from the Calibri font.
So that we can look at it and fix it.

Regards,
Stefan
DIV
User
Posts: 252
Joined: Fri Jun 23, 2017 1:47 am

XPS to PDF bug

Post by DIV »

Thanks, Stefan.
If I've understood correctly, it sounds like the process occurs in two steps:
  1. convert PDF to XPS (by Editor?)
  2. convert XPS to PDF (by Lite)
and only the second step doesn't occur when printing to paper on a physical printer, which may help explain why this apparent issue was not so obvious to other users/testers.

Out of interest, does the virtual printer functionality in PDF-XChange Standard follow the same protocol (i.e. using XPS as an intermediary), and would the same specific "missing o" issue necessarily also occur with that software or not?

Regards,
David
User avatar
Tracker Supp-Stefan
Site Admin
Posts: 17820
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: JOIN pages (opposite of split pages)

Post by Tracker Supp-Stefan »

Hi David,

Our Lite printing driver reports itself as XPS capable to the system - and applications that can handle the format - can send XPS data to the printer. It will take it, and then convert it to PDF, so that you can save an actual PDF file as a result of the "printing" process.

The Editor can do the second part of the conversion - XPS to PDF when you drag an XPS file over the Editor - and display it as PDF.

So the problem is in that process - converting the XPS to PDF - and it affects both of our products that use it.

The Standard drivers are currently using a different process called GDI - and are not affected of the same problem. In the future the Standard driver will become a hybrid - it wil support both GDI and XPS - allowing applications to pick the one they support better - for better results when generating the PDF files.

Regards,
Stefan
Post Reply