Can you tell me what I did wrong when changing over from standard rml reporting to webkit and still standard rml reports are printed? I do not get any error message, no relevant entry in log file. Installed webkit reporting engine, wkhtml2pdf (of course also entered its path to settings), base headers and the webkit report templates relevant to me (up to now, account.invoice and purchase.order are sufficient to me).
Webkit headers I have not customized so far, but at least default header should be available.
Did I forget anything?
Related
Our customer uses a TYPO3 9.5 LTS and complains about the fact that they always have to activate the "alt" tag in the TYPO3 backend to enter the text. We force our customer to do so to hit the W3C requirements.
So is there a way to activate the checkbox by default in the backend? Or may be to remove it at all and allow to prompt even an empty field there?
All images should have a (global) default entry for these fields(title, alt-text, description). Then you would see this default value and only if you want other values for this usage of the image you need to activate the field to edit.
If your editors only fill in the fields for each usage (probably always with the same data) they do additional work.
Show them how to edit the data in the file-manager (File List module):
Open the backend module FILE-> Filelist.
If you have not done yet: check [x] Extended view beyond the list of files and folders.
Then you will get more icons in this view which otherwise are ony available in the contextmenu.
The important icon is the pencil (edit button). it does not edit the content but the metadata of a file.
If you insist on SEO you probably have installed the extension filemetadata which adds some more information fields and scheduler tasks to extract data automatically.
So the amount of available fields to edit depends on the extensions you have installed, but the basic filds are availe by the TYPO3 core.
If your editors upload new files they should fill in these fields to have the information available with each usage. And only if there is a usage which needs other metadata your editors need to make this fields editable.
I have created a report using Birt 3.7.2 The report behaves exactly how I want when using the web viewer and even when exporting to PDF from the web viewer. However When running the report direct to PDF all pages always show as page 1, causing conditional formatting to break.
Why would the page numbers work correctly to the viewer but not direct to PDF. Is there a workaround. The report is called from our application and attached to an email. As such we do need to be able to run it directly to PDF.
The page numbers are on the report body rather than in the Master Page.
I did see this was a bug in 2.6.1 but it was resolved in 2.6.2.
I’m having an issue with PDF output being rendered in Adobe Reader’s ‘in browser’ feature from an ASP Classic site.
I have a form with a handful of inputs that trundles off and makes a PDF report. The report renders correctly (all input values accounted for) when saved as a file, but gives a blank screen when displaying in Reader v7.0, and goes straight to a no-input-values report in v8.1.2.
Pressing ‘refresh’ in the browser from here will also display a report indicative of none of the HTML form inputs being carried forward.
Are there any basic mechanics of the
HTML form post-back that I may have
left out?
*The one thing that puzzles m*e is that un-checking the ‘Display in-browser’ option in Adobe Reader and not restarting the browser gives the correct report in both versions.
The other possible issue is something to do with the browser’s ‘Trusted sites’ policy. The domain had been added to the trusted list, and:
The HTML input form shows as a trusted site in the status bar
The in-browser PDF screen displays at ‘Unknown Zone’
To clarify:
If the Reader is uninstalled, the downloaded file is correct
If Reader is installed, and set to not display in browser, the output is correct
If set to display in-browser with Adobe Reader, it
v7.0 – Displays a blank screen. ‘Refresh’ goes to a no-input-value PDF report
v8.1.2 – Displays the no-input-value report
Un-checking the ‘Display in-browser’ option in Adobe Reader and not restarting the browser gives the correct report in both versions
There is a working old production environment, which is capable of displaying the PDF file correctly in-browser with Reader v7.0 on the same machines we’re testing with. The issue described occurs with the same code being set up in a new environment with tighter security control.
The environment also uses older technology, which won’t be upgraded. This includes:
The site is ASP Classic
The code is outputting PDF v1.3
Internet Explorer 6. Yes. 6.
Any ideas on why the report isn't always carrying forward the HTML input?
Any help appreciated,
Thanks.
The ASP page that generates the PDF is not getting the values from the form. That is why it is creating a PDF form with empty values. Ensure that the HTML form directly posts to the ASP script generating the PDF. There should not be any response.transfer or response.redirect or 404 redirection that goes to the PDF-generating ASP script.
Ah, dang.
So it turns out IIS had GZIP compression enabled, and the client has an IE6-only rollout. There's much written about IE6's GZIP incompatibility, and if you're looking to conditionally allow it in IIS, there are some solutions.
The white screen is result of it being an ASP page that posts back, and changes its 'content-type' in the HTTP header (to 'application/pdf') - where IIS decides it should compress it, and fails in IE6.
Adobe Reader 8 does a 2nd request, losing the postback values.
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'm having issues with my SQL Reporting Services reports. I'm using a custom font for report headers, and when deployed to the server it does not render correctly when I print or export to PDF/TIFF. I have installed the font on the server. Is there anything else I need to do in order to use custom fonts?
When viewing the font in the browser it looks correct - since all client computers have the font installed...
Thanks Ryan, your post to the FAQ solved the problem. Installing the fonts on the server fixes the print problem, as well as problems with charts (which are also rendered on the server). Like you point out (as well as being mentioned in the FAQ) Reporting Services 2005 does not do font embedding in PDF files. I guess that is okay for now - the most important part was being able to hit print and get the correct fonts.
The reason the fonts didn't show up straight away is answered in the FAQ:
Q: I've installed the font on my client/server but I still see ?'s or
black boxes. Why? A: For the client
machine, closing all instances of the
PDF viewer then reopening them should
fix the issue.
For the server, restarting the
services should allow the PDF renderer
to pick up the new font information.
Unfortunately, I have also seen times
where I needed a full machine reboot
to get the client/server to recognize
the newly installed font.
The PDF files served up from SSRS, like many PDF files, have embedded postscript fonts. So, the local fonts used in the report are converted to a best matching postscript font when the conversion takes place so the PDF is totally portable without relying on locally installed fonts.
You can see the official MS guidelines and font requirements for SSRS PDF exports here: SQL Server 2005 Books Online (September 2007) Designing for PDF Output. Also, this post should provide some help as well: Reporting Services: PDF Renderer FAQ
Aspose apparently also has a component that claims to be able to add custom embedded fonts in SQL Report PDFs.
See Aspose.Pdf for Reporting Services
Aspose.Pdf for Reporting Services
makes it possible generating PDF
reports in Microsoft SQL Server 2000
and 2005 Reporting Services. Some
advanced features like XMP metadata,
custom embedded font and rendering
watermark for pages are now supported.
All RDL report features including
sections, images, charts, tables,
matrices, headers and footers are
converted with the highest degree of
precision to PDF.
I've not tried this component, so I can only share what it claims to be able to do.
Note: I have found that when you install the fonts on the Reporting Services server box, you may need to:
= Actually open the font from the Fonts control panel, so you can see the preview
AND
= Reboot the server box.
And yes, I agree you should not need to do this - but I have seen it work.
Running into the same problem - When you export to pdf, it doesn't render the Free 3 of 9 font. The font is installed on my report server, and does appear when you run the report using SSRS 2005.
The user can print directly, which is nice. And the report renders successfully during an Excel export. But that requires extra steps to print from Excel (page setup, etc.).
What I found to be a workaround is to use CutePDF (freeware).
Just click the direct print button on SSRS, and choose the CutePDF printer. It asks you where to save the file. Open the file, and the barcode fonts render successfully.
We had to install NeoDynamic barcode software to render the barcode as an image since we can't include the barcode fonts in PDF exports.
I have used barcode fonts successfully with SSRS and PDF. You must have the font installed on both the server (for rendering and viewing from the browser), as well as from the client.
When using barcode fonts, there's not really a best "match" for postscript so the PDF does not have a valid barcode font embedded with the document, which just yieds a bunch of garbage text. To solve that, just install the font on the client computer that will view the PDF.