Start a new topic

Text Alignment on PDF render Bad PDF output

When Pitchprint generates a PDF from a template and user input it still will randomly change text alignment in the output. Text blocks will change from right alignment to left alignment and move on the document.  I do not understand why this has not been corrected. The output still moves all over the place and it is unacceptable. Will we ever get correct output of a PDF form pitchprint. If a text block is set at an origing point in the document of x 2.0000 and y of 1.0000 (assuming that we are using good practice and are using 4 digit precision regardless of unit of measure) wen the pdf is rendered the d*** output should be exactly where the object was placed and at the size it was placed, typed or edited and with the text block alignment, returns and line spacing.


We still see scaling of svg's and as well wher th euser sets the SVG to a size and when the pdf is rendered the object will be scaled down about 10 to 20% to the bottom left.


3 people have this problem

Is there any progress being made  to identify and correct this issue? Here is a typical example, brand new order and everything moves where ever it chooses on the pdf out put so we have to manually correct each and every order that come through the system. As you can see the type just wherever it choose. I will move differently each editing session. A PDF should be press ready not a document that you have to edit manually every time you get an order. How do we proceed???





The problem is the style font!


If you try to not use bold, you do not have problem!


TRY


Isaac,


We have frequently the same problem with the font moving in the jpg output.

And  as Ken, we have to reedit our order to print it for our client.

This takes a lot of our times.

And as you know (and I often repeat ;-)) time is money...


That's a major issue. There is a bug somewhere, maybe something like the one you solved with element positioning and sizing issue.


Could you please take it as urgent.


Thanks.

Sylvain.


@Jimmy : not using Bold is not a possibility, we can seriously propose to our client.

Jimmy/Isaac


we have processed thousands of orders with thousands of different google type faces and different SVG's. The point is if we set the alignment as right and the data point for alignment for that text block is right then the anchor point for that text block should be the bottom right side of the text block and the text block should flow from those x and y coordinates.  When the PDF is output the engine being used to generate the PDF it will randomly change the alignment ( from right alignment to left alignment ) and it will change the x,y coordinate location and move the text back and forth all over the page.


2. With SVG's the engine will arbitrarily scale objects that have been set to a size in the editor and saved as such with use set x, y coordinates.


Please understand we mean no ill will to any one and appreciate everyone's hard work and want to see Pitchprint improve and are willing  to help that happen. We hope you realize that. We will continue to discuss issue and hope to be able to help people become more successful.




Here is yet another example of a pdf gone wild, Note we have fonts that are not bold and they are running all over not to mention the SVG that was totally destroyed when it was rendered.



pdf
Hi Ken

Just chipping in with my findings, we are a couple of weeks away now from launching our PP V8 site (have had V6 for several years running like a dream) I have noted the constant complaint of the text position shifts and have tested the fonts I was using on our V6 site (approx 60 fonts) and have found that about 20 of them have serious shifting issues when rendered to PDF. Its either a kerning change or a ranging change, or both, its much more prevalent on centre and right justified text. Sometimes its just the bold variant that's affected. We have decided to change our fonts to only ones that don't do any shifting, its a bit of a chore, but will save us never ending headaches in the future. I know its not a solution, but prevention is better than cure. My advice to anyone using this software is to thoroughly test ALL fonts BEFORE using them, the fact is that some fonts (approx 30% by my experience) are simply not compatible with the current V8 pitchprint, for whatever reason, even some of Isacc's demo fonts are doing it.
The SVG corruption I see in your screengrab Ken is exactly what I was getting on my pic library when I checked it (we have approx 1500 SVG's) and I was a bit depressed until I discovered it was simply a converting problem that happened at upload, I simply deleted the SVG, reuploaded it, and they all worked perfectly, must of been a glitch in the system when originally uploaded. Main pain with that fix is all templates using affected SVG's will need to be edited to remove the original version and replace with the fresh upload. This has to be done because Isaac's software stores your template with complete copies of everything placed into it at the time of creation, there is no linking!
Hope this helps someone.

Steve

 

Just another quick add on, I too would rather Isaac fix the font moving problem properly as well, if he is listening :)
Another interesting thing also about the SVG rendering I discovered, the most used shape in the whole tool would be the SVG square and the one provided by Isaac in the default is faulty! If you note when it places it has a small gap between the shape edge and the control handles, this is wrong, it will lead to position shifting when rendered in PDF. The solution, create your own in a program like Inkscape and make sure the shape and the page are identical (there is an option in Inkscape to make page fit contents) save and upload, there will be no more shape shifting! Works the same with all regular shaped SVG's (pentagons, hexagons etc)

 

Many thanks Steve for this information. I appreciate the community beeing created around Pitchprint.

All together we can get the best of this tool.


Could you please provide your list of "good" font ?


It would be really kind.


Thanks.

Sylvain.


1 person likes this

Steve,


Regard the SVG 's we have noticed the same problem, the app he is using to process uploaded SVG's will not process them the same way twice. It will also scale what ever you upload to some random size. We have spent many hours replacing svg's and find it disturbing that the underpinnings to this application ( foundational elements) are inconsistent at best.  I wish we would be able to see a consistent input  / output from it. There should be published rules as to best practice for creating svg's for this app. i have my own preferences that usually seem to work well.

It seems that cloud convert does not provide a setting to determine what level of precision is used and whether to apply scaling etc.  It is a complete mystery to me how it determines it out put. If you were not aware you uploaded files have been processed through cloud convert (www.cloudconvert.com) before they are used in your design or library.

We'll get this sorted. It has to do with the font. Few fonts render very awkwardly OpenSans (and its gang) happens to be one of them.

Remember we are moving from two different environments here, the html browser and then to a PDF engine. So even though they are positioned correctly, if browser rendering of a font differs from what PDF will show, then there will be displacements especially with anything center or right alignments.


If we have a couple texts to render, all aligned same right or center and the two medium render the fonts differently, then one perhaps is normal and another fatter, then the fatter will overshoot that right edge or if slimmer, undershoot the right margin even-though they all are well positioned on the correct x (left) margin.


That's what's happening here and we will get that font to be correctly rendered on the canvas so the PDF will be an exact look-alike.


Thanks.

Isaac,


I understand your statement; but if the text block is set to right alignment with an x coordinate of 3.0000 inches (to the bottom right of the text block assuming that the 0/0 data point for the canvas is the lower left corner ) and the y alignment of say 1.000 inches and it flow from the right alignment to the left. The location and alignment of the text block should be saved to those coordinates.  The alignment of the text block in HTML 5 is also set to the right. Even if they use slightly different kerning tables it would render very close to the original.


What you are saying is that the anchor point and alignment data that is saved from the HTML 5 editor is completely ignored by the PDF rendering engine and that the location of an object on the canvas regardless of it;s x and y coordinates and alignment and size is ignored. 


My suggestion is that the Size, Alignment and Anchor point data be passed to the PDF rendering engine. This will solve most of your problems. Even if the Kerning and word spacing is slightly different it will produce a consistent out put. Secondly the Kerning table for the font uses should be loaded prior to rendering the pdf to ensure 100% accuracy

Have found a temporary fix for this issue, instead of downloading the PDF via the normal link (download pdf file), if you open the clients design as if to edit it and create a PDF using the button at top right, the PDF created is always perfect. Don't know why, but it has solved our text shifting problems until Isaac comes up with a fix, and its not even much more work, just a page load and one click.

 

Steve,


This doe not fix the problem in its entirety it works for some simple issues but the system sis still shifting position size alignment and re-colorizing svg. I appreciate you desire to support Isaac. We want it to succeed also, at this point since input designs don't ever match output correctly there is still a serious and fundamental problem with the engine. the basis for web to print is accurate output. That can not be excused.

Login or Signup to post a comment