We have a WPF application which can perform either a report preview or a report print.
Both requests use the same code.
Call the report service which gets the report from Microsoft Report Services.
Convert the report into the desired format (in this case PDF).
Then return the report as a byte array.
The result is then written to a temporary file as a binary stream, and either popped into a window to preview or start a Process to print.
In both cases the temporary file is passed.
Print Preview works flawlessly! But Print Report will print with all occurances of 'ti' disappearing. I see there is a printer escape sequence of ESC t NUL/SOH and I assume that if, for some reason, an escape character gets into that stream that ti will result in an ignored print sequence. Thus the missing characters.
My first question is if anyone has ever experienced this with generated PDF reports?
My second question (obviously) is if anyone knows of a utility I can use to view the binary data in the file being printed, to see what is in the file just before every 'ti' sequence?
After a great deal of searching I came across a post on the Adobe forum that states that version 8 had a bug where it was not printing character combinations. Once I dug deeper it seems that it has returned and the suggested workaround fixed our issue.
Workaround: Do a print as image.
Adobe seems to be unable to do the most basic of what their software must do, print the exact content!
Answer for your second question:
First, do one of the following two things:
Set the Windows print spooler properties to not delete printed jobs.
Pause the target print queue.
Then, grab the spool file from the Windows printspool directory (which location that is you can find out by looking at the (right-click) 'Properties...' dialog of the 'Printers and Faxes' folder).
I realize this is an old post but I wanted to add some updated info from the above comment stating that it's a problem with Acrobat 8. We are using Acrobat 10.1.6 and still have the same problem. From what I've read, it's a problem with the adobe product itself. The only real fix I've seen (actually work around) is to print as an image. LAME
Surprisingly this bug is still there in 2021. Adobe cannot be relied upon printing documents properly. This takes away all the allure of features it had if it cannot do the most basic stuff it is required for.
Printing as image reduces the quality and blur the document.
Simply open the document with Safari or Chrome and print from there. E
I had a similar problem while printing directly from the firefox (acrobat reader within). I downloaded the file and then printed. The problem was solved.
Related
I am creating a separate question, stemming from this one. The used code is almost the same. The reason is that the original problem was about subsetting a font with pdfbox, which I kind of dealt with. I got faced though with another problem, which is : the annotations, and how the fonts used in them are interpreted by particularly Acrobat Reader DC.
I tried different combinations of fonts and embedding options and got rather desperate. The fact is that I had a feeling that in particular the way these things are handled by the programs that interpret the PDF files is non-standard. I think I read somewhere that the annotations and the way they are displayed is on purpose non-standardized by the PDF format, to give freedom to the interpreters to handle them in their own way, since the main purpose of the annotations is the interaction with the user. TL;DR I cannot understand why Acrobat Reader DC doesn't like the annotations I have created and saved with PDFBOX. I even opened a question on friendly and helpful Adobe's User Community forum. But as I expected, someone suggested me to better investigate this question with the PDFBOX team.
Everything is possible, but rather than writing a question on PDFBOX mailing list (I could never get used or understand the efficient use of the mailing lists btw), I want to open a question here because I hope that it could help others to understand the PDF format better.
I basically rephrase the above question from the Adobe's forums here: Here is an example (Google Drive link) with FreeText annotations (but it seems to make no difference if I use Stamp annotations instead), it causes problems when open by Adobe Acrobat Reader DC (file) version 21.001.20149.37945 (I think this corresponds to April 16th '21 update). Specifically the problem happens when the Comments pane is opened by the user, either manually or automatically.
Manually:
link
Automatically:
link
While experimenting, I also tried to unset the "Use local fonts" option in Preferences -> Page Display. I had the impression that maybe Acrobat Reader will be more eager to show the error message once it is not allowed to substitute the erroneously embedded fonts with the possible local fonts. I am not sure if this is true.
The error that I get is the infamous "Cannot extract the embedded font XXXXXX+SomeFontName" as seen in the below picture:
link
The same problems happen also if I use full font embed (subsetting option set to false when using PDType0Font.load). I also tried to embed OpenSans font instead of LiberationSans, also tried to manually convert LiberationSans to a TTF font with fewer glyphs using FontForge, even tried to use Windows ARIALN.TTF, thinking that maybe the font is the problem. All cause the same behavior in Acrobat Reader DC. I have also tried to run Acrobat Reader 2019 Pro Preflight on the document and in the profile that scans the document for the possible font inconsistencies, it reports no errors.
Of course, when I use e.g. PDType1Font.HELVETICA instead of custom TTF font, I do not get the above errors. But I cannot use it because it does not contain the glyphs for the Unicode characters that I use. Does anybody have a better idea?
Thank you very much!
EDIT: to make myself clear - the error does not appear ALWAYS. it appears on some machines constantly (e.g. I am using Windows 7 64-bit with latest Acrobat Reader DC installed to reproduce it fairly well), while on my Windows 10 64-bit with the same version of Acrobat Reader DC it sometimes appears, and sometimes not - I haven't figured out why or in what cases.. - which makes me think - but no - I checked that too - the font I am using opens up alright on the machine where the problem is fairly constant)
UPDATE: at my wits ends again, I created a blank page with Apache OpenOffice, exported it to PDF, opened it with Acrobat Reader DC (last version), added a FreeTextTypewriter annotation (View -> Tools -> Comment -> Open) with 4 greek letters in ArialNarrow font, saved it, reopened it with Acrobat Reader DC, and it gives me the same error (cannot extract the embedded font...).. So this could be the Reader problem? But they made this so difficult to diagnose.. Here is the file, but I do not expect it to show errors on other machines. It's one of those moments that you start to believe in magic and the power of prayer (and a good sleep)
UPDATE 30/04/2021
So, to sum things up, I haven't come with a solution yet, but I came up with three files created with PDFBOX, OpenPDF (iText5 fork) and Acrobat Reader DC itself (can append annotations and save - just adding a simple Text box with greek text through Comment pane) - and they all issue the above error message, when open by Acrobat Reader DC. I have posted details in the Acrboat Reader forum here (same link as in comment)
I have added the code that I used to create the OpenPDF example file here and the example 3 files are in the same repository here
I been looking all around for a solution to my issue but i can't find a fix yet. Here's my problem:
I have a dynamic PDF which contains a table and several text fields per row that grow vertically as the user adds text (multiple lines and expand to fit vertically). The table properly breaks when the content doesn't fit in the current page, however, I found out that in some scenarios, with a certain amount of characters, the row sometimes overlaps the content in the next page (See below).
By by adding more text to the offending line, the content in that row properly breaks to the next page (See below)
I am not sure whether or not this is a known issue with the tool or I am missing some sort of configuration/setting in the template. I haven't found anything online or in the Adobe Documentation. Any thoughts?
I am using:
Adobe Acrobat Pro 9
Adobe LiveCycle Designer ES 8.2
The form version of the PDF runs in Adobe Reader 7.0.5 (For compatibility purposes with one of the tools our clients are using)
Thanks in advance
After a long time looking for a solution, I found a single blog of someone who had the same issue, which by the way Adobe was kind enough to not document it... Anyhow, the following two processing instructions need to be added to the XML
<?layout allowDissonantSplits 1?>
<?layout allowJaggedRowSplits 1?>
My XML looks like this:
<template xmlns="http://www.xfa.org/schema/xfa-template/2.4/">
<?formServer defaultPDFRenderFormat acrobat7.0.5dynamic?>
<?formServer allowRenderCaching 0?>
<?formServer formModel both?>
<?layout allowDissonantSplits 1?>
<?layout allowJaggedRowSplits 1?>
The author specifies that the directives should only be added if this problem occurs. I wonder why these instructions should only be used in this situation. The full blog post can be found here:
http://blogs.adobe.com/dmcmahon/2011/10/10/lc-forms-es-text-overlapping-on-page-break-using-nested-subforms/
Hope this saves time to someone else
I'm using ActiveReports 7 PRO and cannot get the reports to print correctly. It sends the document to the printer however it's all blank. I'm needing to print a bunch of reports in a loop so I'm looking to do this all programmatically. Here's the code I'm currently using after the DataSource is set, etc:
rptPT.Run(True)
rptPT.Document.Printer.Print()
I can't seem to load it into a viewer in the loop and print it that way (nor do I want to) because it tells me that the report has not been loaded fully. Like I said, it prints, however it's just a blank page with nothing on it. Also: if I export it to a PDF everything is fine in the PDF document.
Thanks!
Please refer to the following forum post wherein similar issue has been discussed and resolved :
http://our.componentone.com/groups/topic/printing-blank-pages-2/
See if this helps.
Regards,
Mohita
We have a large number of Omniform files (around 100,000). We're updating our main server OS from Windows Server 2003 to Windows Server 2008. Omniform isn't supported in Windows Server 2008 so we need to convert these files to pdf (or another viewable format).
What I've tried so far:
Using Print or PrintTo verb from inside a program using Process.StartInfo and using a PDF Writer printer.
Using Print directly from a command line using the Print verb with the PDF Writer set as the Default Printer:
C:\PROGRA~1\ScanSoft\OMNIFO~1.1\OmniForm.exe /p "Test.ofm"
Both of these Print successfully and a PDF appears. However it prints only the Form, not the Form with the entered in Data. Namely you'll get Last Name then a blank instead of showing the entered last name.
If I print to a normal printer and not a PDF Writer I get the same behavior. Form only with no entered in data appearing.
I've tried calling Nuance Tech Support and they suggested doing them manually 1 at a time. Given this would take someone about half a year of full time work to do, that's not a viable option for us.
So what I'm looking for is a solution to the command line print above
If an "image" of the filled-in form might work for you, Omniformat might help you out. It basically converts the file to pdf using a print-to-file method, but it might help you out, since it does batch conversion.
UPDATE: I wrote to Wolfram support about this and will update the post if they can resolve the problem. Sorry for spamming SO with a technical support question, but here it remains in case anyone else is having the same issue.
Is anyone else having this problem with Mathematica 8? I recently upgraded and noticed that when I export Graphics to a PDF file, although the file appears fine on my computer, it prints as a blank page. For example, try
Rectangle[{1,1}]//
Graphics//
Export["~/test.pdf",#]&
which creates a PDF file containing a black square. This file opens fine, but if I send it to my department printer I just get a blank page. If I don't export the graphics but print the notebook from MM, no problem, the graphics print as expected. If I use MM 7 to do exactly the same thing, the PDF file prints as expected. Exporting to PNG in MM8 seems to work fine. And, using the context menu Save Graphics As ... or File > Save Selection As ... to create a PDF containing just the graphic also works. However, these graphics eventually get included in a TeX document, and it would be far better if I could continue using the script I've got that doesn't require any button clicking to generate them.
I'm running MM 8.0.0.0 on Mac OS 10.6.7. I have not been able to test this on another printer yet, but this printer has never given me problems before and prints other PDF documents fine. Any ideas why this is happening?
Wolfram Research responds:
...
This issue has been reported by other users as
well and our developers are currently looking into it. I have added your
details to the report so you can be notified when this is resolved.
In the meantime, the alternatives that you could try are:
Try a different printer.
Rasterize the image with the function 'Rasterize' before exporting. If
the rasterized image loses some resolution, you could use the option
'ImageResolution' to edit this.
Rasterize[image, ImageResolution -> xxx]
Surely this is a bug (please report it to support#wolfram.com), but you can work around the problem by selecting the graphic and choosing File > Save Selection As... from the menu (or Save Graphic As... from the contextual menu). This produces a slightly different file that doesn't appear to exhibit the undesirable behavior we observe from Export[].
These problematic files, and LaTeX PDFs that include them, can be properly printed by Adobe Reader 10.1.2. That's if you're okay with installing and using a 450MB PDF reader.
I reproduced the problem (leading me to this question) with Mathematica 8.0.4.0 on Mac OS X 10.7.2. Wolfram suggested lame workarounds like Rasterize and told me
This issue has been addressed by our developers, and a fix will be included in a future version of Mathematica.