So that the link can be used in some external applications, and users in that application can click the link and navigate to that specific location (text or area) in the pdf.
Is this possible?
There are several different URL # (fragment) constructs that were introduced by Adobe for use with their web browser PDf viewer plug-in. The current accessible list is at https://pdfobject.com/pdf/pdf_open_parameters_acro8.pdf
Many newer competing PDF enabled browsers may use similar, but there is no guarantee one URL.pdf#Fits all. Most will respect #page=number&zoom view or fit but it is very variable, thus you need to check each feature across browsers.
Important to switch off any PDF remember my view settings
For your previous request using Bookmarks can be unreliable (as can the comments ID) unless you are using Acrobat and can check the bookmark function. By far the more reliable may be the use of zoom at a scroll location so here using MS Edge:-
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" file:///C:/Users/.../Desktop/CEI-PID-Sample-Rev4annotsC.pdf#zoom=300,200,200
I support SumatraPDF however its browser plug-in whilst still functional is way past EOL thus unsupported, it had a limited support for those fragments even though the CLI was recently extended for some Acrobat /Action commands.
However related to your desire the one single portable EXE can jump to well formed text blocks. Here I call "V 4508" in a fairly similar fashion
"C:\Program Files\SumatraPDF\SumatraPDF.exe" "C:\Users\WDAGUtilityAccount\Desktop\SandBox\apps\Graphics\CEI-PID-Sample-Rev4annotsC.pdf" -zoom 300 -search "V 4508"
And if I press A then the text will be highlighted for comments
I have built an application that automates the filling out of form fields inside a pdf. It then takes various assets and combines them together to generate a "print ready" product. All of this is accomplished using the magic of iTextSharp. When form fields are populated, they are then flattened to text. The problem is that even with the fonts embedded they aren't really attached to the form fields in a meaningful way (like straight text elements are) and the printers are complaining that the pdf is generating licensing errors due to this. I researched this a bit and it just seems to be the nature of how form fields are.
The artists we are working with requested that we research a way to "outline" the text that is created from flattening the form fields. I found that running the PDF Optimizer with a custom preset allows for Text Outlining in Acrobat, and even better I can generate an Acrobat Sequence that runs this command on the pdf. The problem is that Sequences can not be automated, at all.
I found a plug-in called AutoBatch that allows for the execution of Sequences on the command line through a batch file. The downside is that this would require installing Acrobat Pro and the Plug-in on the server this application will be running on. Further it seems like an overkill solution just to outline the text in the pdf. For all I know at this point iTextSharp may allow me to do this programmatic, but searching for such a thing on google returns little results and nothing relevant.
So the question: Is there a better way to outline text in a pdf than the current solution I have implemented or am I kind of stuck?
TLDR; PDF is generated w/ non-standard fonts. I need to "outline" this text to send it to the printer. Currently using AutoBatch Acrobat Plug-In to execute Acrobat Sequence from the Command Line. Seems excessive, wondering if anyone knows a better way to automate font outlining.
I am also in a printing environment and have used forms for "Box Covers" plenty of times to shorten the code used to produce box covers.
I simple us "pdfStamper.FormFlattening = true;" and the printers (Xerox DP180 and DC5000) has no problems in using the PDF.
The moment I leave out FormFlattening the printer gives a lot of errors regarding the PDF.
If you are using FormFlattening then check if the printer has the font locally installed in order for it to reference the font from the print engine instead of the PDF resources.
I'm working on my first significant Sql Reporting Services project and am having problems with paging. Most of the reports are already working.
What is happening is that I"m getting different numbers and locations of page breaks between Web Reportviewer, PDF and Word documents. The word is the closest, but none of the three are really correct.
I've looked for the for the obvious like extra paging and making sure the report does not go outside of the left or right margins. My problem is that I'm not sure how to go about troubleshooting reports that pages that do not break in the correct location.
Does anyone have a suggestion where to start?
I'm using VS2008, SQL2008 DE on Vista Dev box.
This isn't really a problem - the different renderers are rendering the report appropriately for their output. The web viewer is optimised for screen-based reading and generally allows more content per page than the PDF viewer does as the PDF viewer is constrained by the paper size that it formats to. Thus you get more pages when rendering for PDF than web; however, the content of the report is exactly the same.
The best illustration of this is the Excel renderer - the Excel renderer renders the entire report onto a single worksheet in most cases (for reports with grouping and page breaks set on the group footer it will render each group on its own worksheet). You wouldn't want the Excel renderer to artificially create worksheets to try to paginate your report. It does the appropriate thing which is to include all the data in one big worksheet even though that may be logically thought of as one big "page".
The web renderer page length is determined by the InteractiveHeight attribute of the report (in the InteractiveSize property in the Properties pane for the report) but the interactive height is an approximation rather than a fixed page break setting and your page breaks may still not conform to the PDF version even though the InteractiveHeight is set to the same length as your target page length.
I am working on a legacy app in VB6 and am wondering what the easiest way would be to implement this requested feature - client wants ability to preview a document being sent to the printer as a PDF. No problem - there are plenty of PDF printer drivers out there that one can use. However, a necessary condition of this feature is absolute transparency - in other words, it should work out of the box after installation of the app, without having to say "To use this feature go to such-and-such website and download this pdf printer driver." In addition, client does not want to see a "Save As..." dialog. The ideal function of the feature is that a button is clicked, and what would have been sent straight to the printer is instead instantly previewed as a PDF that pops up with no further interaction with the user other than the user's initial pressing of a button.
Of course, there are a gazillion PDF packages out there, but they all seem to be along the lines of "here's an API where you can generate PDFs by directly writing lines, circles, graphics, text in specified fonts right to the PDF file". I do not want this - I want something that takes the data that is going right to the printer and pop it up as a PDF without a Save As
Now, CutePDF seems to have something like what I am looking for with their Custom PDF Writer (http://www.cutepdf.com/Solutions/pdfwriter.asp), but a) they do not seem to have an evaluation version; b) they do not seem to have much documentation about it that I can see, and c) it's freakin' expensive
Does anyone know if anything else like CutePDF Custom PDF Writer exists, or is that the only one of its type? I am open to any software as long as it gets this done, be it commercial, shareware, open source, whatever, so long as it satisfies the requirements of:
Must be a PDF printer (i.e. take the data going to the printer and turn it into a PDF)
must be completely transparent to end user (i.e. user must not have to change their printer settings and then change them back, or deal with a Save As dialog and then open the file they saved - it needs to just pop up)
must work with VB6
must be able to be packaged and installed along with the app without the end user having to run another setup program
any ideas?
Thanks in advance :)
We've started using Bio PDF Writer, available here: www.biopdf.com.
It does offer the ability to silently install (which we do). It also offers the capability to write out to a pdf file silently, requiring an ini file to be created first to do so.
However, it is more expensive for a site license than CutePDF is (1,499 vs 299/499). you can buy a single license for 29.99 (USD). This may cover their needs (if it is just one client). Their documentation is pretty decent and they do have a trial version (that, as far as I can tell, has no limitations to it).
You should be able to use any PDF printer software that provides a silent install option and just set the current printer when you need to print via PDF:
Dim oldPrinter as VB.Printer
Set oldPrinter = Printer
Dim p as VB.Printer
For Each p In VB.Printers
If p.DeviceName = "PDF Printer Name" Then
Set Printer = p
End If
Next
' Print Document Here '
Set Printer = oldPrinter
Note: You will need to ensure distributing and installing isn't in violation the license agreement
I created a simple report and uploaded it to my report server. It looks correct on the report server, but when I set up an email subscription, the report is much narrower than it is supposed to be.
Here is what the report looks like in the designer. It looks similar when I view it on the report server: [http://img58.imageshack.us/img58/4893/designqj3.png]
Here is what the email looks like: [http://img58.imageshack.us/img58/9297/emailmy8.png]
Does anyone know why this is happening?
This issue is fixed in SQL Server 2005 SP3 (it is part of cumulitive update package build 3161)
Problem issue described below.
http://support.microsoft.com/kb/935399
Basically Full Outlook 2007 Client Uses MS Word HTML Rendering Engine (Which Makes Web Archive Report Looked Jacked Up).
NOTE: Web Outlook 2007 Client Uses IE HTML Rendering Engine (Which makes Web Archive Report Look Okay).
We have installed the patch on DB housing Reporting Services and it does fix the issue. Emails look all nice and fancy now.
I notice that the screenshots show Outlook 2007. Perhaps you're not aware that Microsoft somewhat hobbled the HTML capabilities of Outlook in 2007, and now it uses the Word HTML engine, and not the more advanced Internet Explorer one? Might this explain the lacklustre appearance?
http://www.sitepoint.com/blogs/2007/01/10/microsoft-breaks-html-email-rendering-in-outlook/
I got around this problem by doing the
following:
Add a Page Header to the report
Add a line to the page header. Set the width of the line to the
desired page width.
Set the line colour to white (eg to hide the line)
Hope this helps someone else,
Following on from girlC0d3r's solution, images aren't always guaranteed to be shown in an email.
A better solution to widening the report to prevent the content from wrapping is to have a long unbroken string of characters with no whitespace.
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
By giving the text the same color as the background of the email (e.g. white) they'll widen the report and be invisible to the user.
I don't see anything but my first guess is that the fonts are vastly different. The designer has one font and the email is a flat, no-frills kind of thing with a simple font. Without concrete examples, this is just a guess.
I don't think it's a font thing, because the text is being wrapped a lot, and it looks about the same size.
The images show in my preview, but not in the final post. So, here are links to them.
Report in the designer: [http://img58.imageshack.us/img58/4893/designqj3.png]
Email result: [http://img58.imageshack.us/img58/9297/emailmy8.png]
What report output format did you specify for the scheduled job? It seems to me you used HTML, which will autoscale depending on the output browser (HTML adapts).
If having the same layout is important then use PDF as the output format. Then, if the user wants to print the report you know exactly what it will look like and that it will fit nicely on the page.
Can you try a different format? pdf or xls maybe. In my experience web archive looks goofy. Don't know why.
Yeah, I'm using HTML. I would prefer to stick with that, because the users can just read it in their mail clients. PDF or XLS would require them to open an attachment.
I know that the HTML resizes itself to fit the browser, and that's a good thing. The problem I would like to fix is the wasted space - in the email client, the HTML shrinks too much.
I got around this problem by doing the following:
Add a Page Header to the report
Add a line to the page header. Set the width of the line to the desired page width.
Set the line colour to white (eg to hide the line)
Hope this helps someone else,
girlC0d3r is along the right lines (no pun intended), but the line will likely be shrunk along with the rest of the HTML in the email. A workaround I used yesterday was to create an image 1px high by 600px wide (or whatever), the same color as the background, and bring it into the report as an embedded image. Place it above or below the body of your report. This should force the intended width in the final email. I used this technique successfully in a report yesterday.
I just ran into this issue myself, exactly as portrayed in the OP's screenshots. The reports were beautifully rendered in nearly every format except for Web Archive. My trouble was the use of a rectangle containing each matrix that did not span the width of the report. Upon stretching it out through the remaining white space, the condensing behavior ceased. Hope that helps someone who doesn't have quick access to an SP upgrade!
Where it is not an issue of running on old software that needs a patch...
The reason is the columns are different sizes is because the MHTML Device Information Settings, 'OutlookCompat' is set to true
When creating an email subscription with MHTML format and open the report in Outlook, A forum post by Microsoft employee Fanny Liu says
change the OutlookCompat configuration setting for the MHTML Rendering extension in rsreportserver.config. Set the value to: False.
As I was researching it appeared that this would impact more than just column size. In my instance it was not that big of deal so I decided to leave well enough alone. It is correct in PDF and web, the email I send includes a link back to the report, if the client wants a pretty report they are going to want it in PDF, the email format is not expected to be printable.
Encountered the same issue and this worked for me.
Go to --> Properties --> Report
Set InteractiveSize Width to 4.9in
Set Margins to 0 for Left, Right, Top, and Bottom
Set pageSize to Width to 4.9in