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.
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!
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.
@Jimmy : not using Bold is not a possibility, we can seriously propose to our client.
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.
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.
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.
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
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.