I have a report that renders perfectly fine on screen, but when I export it to PDF one section is rendering the font HUGE, making it unreadable. The part that is getting rendered so big is a field I have set up to store rich text, which then gets converting to html. I did not roll this solution myself, but from what I understand it runs an rtftohtml method to render to the screen, and then it runs through the same method again to re-render it to a PDF, which is why I am confused. The first rendering (to the screen) looks perfect, and then the second rendering (to pdf) looks like garbage. I have seen a few threads on this topic in some other forums but not a single one has a response, so I am hoping the SO community has a possible work around or fix for this!
Related
So I'm trying to build a mid-complex invoice for an app, but I'm having many problems getting the right layout printed, and I don't know the reason, I have tried some of the things.
So this is the design before I'm printing it (the React-pdf template):
So I want you to pay attention, to the items below that are iterated and printed. (Don't worry the logo will be shown on the print page, I don't know why is not showing by default on the design page).
And here is the template after the print, that the layout of items is broken, and it doesn't show the one I designed. But rather something else. Here it is:
Here is the live link to the React Pdf Editor, so you can check the code (because is to long for here):
React PDF Editor Online
We are trying to improve handicapped accessibility of one of our pages and allow a user to perform all the actions without a mouse. The page contains some buttons and an iframe with a pdf document. In IE11 I can tab through the buttons but when the control goes to the pdf viewer iframe, nothing is highlighted and pressing tab doesn't do anything.
In chrome pressing tab will cycle in through the buttons, than the handful of controls on the pdf and than step out of the viewer and start to cycle again. How do I get IE to do the same thing.
As a side note if I use shift+tab to cycle backwards, IE will ignore the iframe and cycle through the elements correctly. In fact after tabbing into the iframe, I can use shift+tab to get back to the button controls.
Any help would be greatly appreciated.
It sounds like you're trying to test PDF accessibility in the browser, which isn't really how things are done. The PDF viewers in web browsers are inferior to Acrobat, and people who need assistive technology likely won't be using the PDF readers built into IE or Chrome anyway.
As a starting point, I'd recommend opening up the document in Acrobat and making sure that it has tags. If it doesn't, you can try to have Acrobat generate them for you. If you're using any kind of a complex layout (other than simple text, images, and maybe lists), then the tagging will probably require you to manually review and correct them. PDF tags are structured very similar to HTML (but not entirely identical). If you already know HTML, then you'll probably be able to tag PDFs well enough. Otherwise, there's going to be a learning curve.
PDF remediation is an art unto itself that takes some time to master.
Here are some resources that will hopefully point you in the right direction:
https://webaim.org/techniques/acrobat/
https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html
https://www.washington.edu/accessibility/documents/pdf-acrobat/
My SSRS rdl report is rendering differently in the ReportViewer in an ASP.NET application than it does in BIDS (for this project we are on SQL Server 2008 R2 and BIDS). It renders the way I want it in BIDS, but the Report Viewer changes the placement of some of the textboxes. Specifically, it's pushing some text boxes down the page and creating a large area of whitespace.
I am using version 10.0.0.0 of the report viewer DLL.
Running the report in the ReportManager web UI in SSRS displays the report the same way as in the Report Viewer (not the way we want it).
BIDS is on SQL Server 2008 R2 SP3.
Ideas on how to mitigate this?
SSRS report elements when rendered in certain formats such as HTML cannot overlap in any way, whereas in the VS/Report Builder preview or formats such as PDF they can.
Due to this, if you aren't very careful to avoid these overlaps in your design you will see a different layout in the ReportViewer where SSRS has 'pushed' your report items around to remove the overlap.
We have similar issues, but different versions of SSRS. This page and many similar ones give information about rendering, but none of them seem to answer the questions "does this text fit in this box?" and "How big will this box be?" Rendering to IE, Chrome, Safari, Word, and PDF was an exercise in frustration and compromise, especially considering that Visual Studio and Report Builder were also different. In all cases, the height and width of the text boxes changed, the font size changed, the spacing around the text changed.
Our technique was to prioritize the various output formats, then find settings that produced the best output based on those priorities. Given this, users see better (but still not quite perfect) results than we see in Visual Studio.
I was able to find a solution for our particular problem by minimizing scenarios where SSRS will resize an element during rendering. For example, we had a text box that had the default height on the canvas (roughly the height of one row of text). The text had an expression with HTML content that included several line breaks. This caused SSRS to resize the textbox and push other elements down the page, even though there was space to fill without moving other elements. When I increased the height of the textbox on the canvas to fill the available space, SSRS stopped moving other elements around on the page.
My lesson learned is to set the size of an element on the canvas based on how big it is likely to be when it's rendered. If SSRS decides it needs to increase the size of an element, it starts moving other elements around on the canvas (even if there is space to fill without moving things around).
I have a very pretty calendar report that I've created on one machine, that shows my company's daily revenue as a color coded block for every day for the past several years. After finally getting a color scheme down and pretty much finalizing it, I went to test it on another machine - and hit a rather large obstacle.
This is the report that I used as a template:
http://bl.ocks.org/mbostock/4063318
It's awesome. And, inside Internet Explorer 11, it looks fantastic. I never would have expected that copying the code and testing the report would produce a blank page, but there it is. On that page, the calendar report is visible. In IE 11. Copying the code to a new html file and opening it, shows nothing. In Firefox, however, everything is visible. as is.
Now, there's a part of that page that points to "//d3js.org/d3.v3.min.js"
And I figured out that in order to make that work in firefox I had to add the http: in front, so that's not my issue.
I'm literally sitting here at my desk staring at two browser windows open and pointing to the same html file. One contains my beautiful report, one is a completely blank page.
Some cursory google searches reveal that IE 8 or lower have issues with the svg. I can't seem to find any references on someone having a similar issue though. Their situation seems to be that with IE10, you need to specify the height and width, not just one or the other, to make sure everything scales properly.
If I could have my way, I'd just run Firefox on all of the machines that are going to run the report, even if it's just for that one thing! Alas, I am but a mere peasant coder and so I have to make it work. in the dreaded IE.
Are there any svg/html/d3.js coders out there that can tell me another way to spit out the data I'm using so that I can get what I'm looking for?
copying the code and testing the report would produce a blank page
Because you're outputting invalid HTML. There is no html or head element for starters.
Output your code in to a file like example.xhtml and open it in Firefox (specifically) as it's XML parser will very quickly tell you what line and column the first XML parser error is occurring on. You are rendering in standards mode instead of quirks though that does not imply your page meets standards.
var m=(document.compatMode == 'CSS1Compat') ? 'Standards' : 'Quirks'; window.alert(m+'-mode.');
I am having a minor issue playing with my exported Crystal Report, I can generate the reports just fine on our website, however when I attempt to export them to Word documents I don't quite get a document I can do much with.
i.e.:
I can't position the generated text anywhere in the document, it is almost 'frozen' in place. I would expect if I moved the cursor above the report text and pressed Enter a bunch of times I could remove the report down the page, however it just won't budge
All the text seems to be in its own box and I can't move it around or do anything with it.
Any thoughts? My expectation would be once it is exported to Word I could play with it like a Word document, move the text down the page, edit the document, do something with it.
Thanks!
btw, this question is similar to the one posted here, but this one wasn't tagged properly and I don't have enough karma to fix it:
https://stackoverflow.com/questions/434381/word-formatting-not-intact-when-exported-from-crystal-reoport
I'm afraid that you can't do much about it. Crystal Reports is very much orientated towards putting data in fixed positions on pages, so when it exports to Word it puts its data into text boxes because that's a similar thing that Word offers. You could make the Crystal Report page consists of a giant text field and using spaces and newlines to get the data into the right place, which will probably then give you a giant textbox in Word.