PDF XChange Forum

Hi,

I am currently using the latest release of PDF-XChange Editor Pro v8.0.336.0.

I need to write for my company a number of technical documents which also has to include a set of the Google Noto fonts. As my main word processor software I use LibreOffice and then open the file up in Word and convert it with PDF-XChange.

I noticed the following in a test run with a direct print out with LibreOffice:

The PDF-XChange software seems to get stuck in some areas of the document when printing. It eventually succeeds in creating the PDF file but then some of the Noto Fonts are incorrectly embedded into the file and become unusable.

Here are the things that I tried:

- Created said document from scratch again to see if the original document was defective. I saved the original file as text file and copied the other text from Word files that I received. Failure 100 %

- I installed PDF-XChange Pro v6 in a virtual Windows 10 Machine and printed the file out successfully at high speed. The PDF file was good usable

- I removed PDF-Change Pro v6 and installed PDF-XChange Pro v8 into the Windows 10 VM. The issue was reproducible

If I use instead of the Noto font the SimSun font there are no issues at all.

When creating the PDF file with PDF-XChange Pro v8 the only PDF viewer that can open the PDF without issue is the PDF-XChange Editor v8. Adobe and PDF-XChange Viewer fail. The PDF file created with PDF-Change Pro v6 opens flawlessly in Adobe and PDF-XChange Viewer.

I have created some videos and can also provide the source OpenOffice document.

Please advise on how to proceed from here.

Thank you very much!

Reards,

--Christian

Hello Christian Flatscher,

Can we please have a copy of the original file (both OpenOffice and .docx formats please), as well as the results when converting with V6 and V8 of our drivers? We will also need a copy of the problematic font.

If the original file is sensitive - please create a new document - even if it is with just one line of text (if that is enough to reproduce the issue) - and send us the non sensitive document. If you can't post these files here in the forums - please send them to support@pdf-xchange.com with a link back to this topic - and we will check them for you!

Regards,
Stefan

Hi Stefan,

I am happy to supply all you asked for.

The only thing I am unable to provide is the Word .docx file as Word 2016 can open up LibreOffice documents and I can save the .odt file in LibreOffice into .docx format.

Whilst the content of the file is not sensitive I appreciate it very much if it is not shared beyond myself and Tracker Software. Thank you for your understanding.

With the fonts in use it will be around 645 MB of files. The major chunk are the Noto fonts.

Please advise to where I should upload all in one go for your review and investigation. I know that Tracker Software has a special file server for such purposes.

Many thanks.

--Chrisitian

Hello Christian,

You can follow the steps here to upload the file to our server: https://www.pdf-xchange.com/knowle ... le-service
Please place the files into a zip folder with your name on it, after that let us know either in a post here, or via Email when the files are uploaded.

Kind regards,

Hi Daniel,

I have now uploaded the file 2020-01-21_ticket_33754_christian_flatscher.zip to the server.

Here the file check sums:

MD5: 92ADE2BA0761ADB7983AD8025A75DE99
SHA-1: EEBD70D6E62B61E1C088B9836AD1546570E3E78C
SHA-256: E0F89FD899307618339ED3273C73905891C4522710D1D1631B21A8B7912D9952

The file contains the following:

- 2 LibreOffice Writer documents with different main fonts
- 2 Word .docx files converted via LibreOffice Writer
- All font files required for the documents
- PDF files generated
- 2 Videos demonstrating the issue

Thanks for your review.

Regards,

--Christian

Hello Christian,

Thank you for the files here, I have managed to reproduce the issue on this end, and created a formal ticket for it to be investigated by our dev team:

RT#5078: print/convert Font embedding error.

From what I can see, the font experiencing issues seems to be the only font that is not a "truetype" font, which might be part of why Adobe has trouble using it. I am unsure what exactly that means going forward, but I am sure that our Dev team will try their best to resolve this issue.

Until this is resolved, I unfortunately do not have a good workaround for you.

Kind regards,

It is good news that you were able to reproduce the issue, Daniel.

I will try a few things myself and let you know how I got on with these.

I will update this ticket ASAP.

Thanks again!

--Christian

Thanks Christian,

Looking forward to your feedback once you've had the time to try those things out!

Regards,
Stefan

Gentlemen,

This morning I have tried to convert the Noto .OTF files to .TTF using some web service. This took quite some time so I decided to abandon this effort and try some alternatives.

With FontForge I found that it would not convert the .OTF files correctly to TTF. See attached screen shots.
I then also installed the current trial version of Fontlabs TransType 4. I loaded one Noto .OTF font and the application failed to convert it to TTF without any further meaningful message.

It could be that these .OTF files are too large to convert or any other reason could be the case for this conversion failure.

At this point in time - and until this bug is resolved - I have no other choice but to use PDFXchange Editor Pro in my Windows 10 VM to convert these files successfully into PDF. If I am not allowed to do this, please let me know then I will use the LibreOffice integrated PDF convertor.

Thanks.

Regards,

--Christian

Hello Christian,

Thank you for keeping us posted, that will be useful info for our Dev team.

As for performing the conversion in a VM, there is no issue with that so long as only users covered by your license are able to access the software on that VM.

Kind regards,

Thank you, Daniel.

The VM I use is installed privately on my Laptop to which nobody has access to except myself.

Thanks!

Regards,

--Christian

PDF-Xchange Editor has many difficulties in embedding fonts.
since version .335 it is completely unusable for setup texts with correct embedded fonts.

left is a pdf viewed with correct embedded font Editor version is V.331 i think
right is made with V.335 portable.
font isnt embedded.
Whole text looks like
that is crap at 100%.

first I thought its me doing wrong.
but its the software.
Embedding fonts was ever since a very worse function in PlusEditor., and till version 335 it definitely is 100% unusable.
A pdf editor which is not embedding fonts correctly.
therfore you can use MS Publisher and print out pdf pictures...

Hello TCJCM,

May I ask how you are going about embedding these fonts? Currently the only way to forcibly embed fonts with our Editor is to save the document in an archival format (via "Save as" > "save as type:" > "PDF/A"). If you are not performing this process, the fonts that exist on your desktop are likely not being embedded into the document in the first place.

Beyond that, I should not that build 335 is not the latest available, do you experience this same issue in build 336 currently? If so, could you please send us a copy of the documents in question so that we can compare?

Kind regards,

... the only way to forcibly embed fonts with our Editor is to save ... (via "Save as" > "save as type:" > "PDF/A").

since about one year I tested different types of PDF editors.
Xchange Editor has best workflow for me.
Embeddings fonts was a big problem for me with this editor.
And now embedding fonts is "just saving as PDF/A. "
Save as in Editor

Settings in office plugin


Result: applying this settings and the used fonts are completely embedded!
THX, You made my day!!

Hello TCJCM,

Glad to hear you got it working for you!

Regards,
Stefan

Hi,

Please advise what the current status of my problem reported that PDF-XChange Editor Pro v8.0.336.0 fails to properly embedd Google Noto Fonts is.

Do you have an outlook when this issue will be resolved?

Thank you and stay safe during this pandemic.

--Christian

Hi, Christian Flatscher

Font embedding as a whole will be seeing a rework in the future. Unfortunately it is a very large job and will take a good amount of resources to see completion. As such we currently have other priorities, namely the soon to be required "accessibility compatibility" overhaul which we have planned for our version 9 release. Once this is complete, we will choose the next "large" project that the team will focus on, this is one of the primary items on that list, and will likely start seeing action at that time.

I am afraid that I cannot promise any timelines or swift resolutions on this case.

Kind regards,

Thank you, Daniel.