Index > Bug report > PDF Error: Garbled Text
Hi Leo & Everyone
We're getting an issue where all text that is generated and brought into a PDF ends up overlapping itself on a single line. We are using Acrobat Reader 7.0 and FoxIT Reader 2.0 b1606. Both produce identical results. I have added the Meta tag fix that Leo specified in another thread. We are on TL 2.4.3.
Thanks, Leo!
Screenshot:

We're getting an issue where all text that is generated and brought into a PDF ends up overlapping itself on a single line. We are using Acrobat Reader 7.0 and FoxIT Reader 2.0 b1606. Both produce identical results. I have added the Meta tag fix that Leo specified in another thread. We are on TL 2.4.3.
Thanks, Leo!
Screenshot:

Last edited by fbliss, 2007-06-29 15:46
Come to the light... Typolight.
2007-06-29 15:42
This is certainly a problem. I am unaware of a solution though. Anybody?
2007-07-03 15:37
Hi
Whatever article i save as pdf, the file name is always read-articles.pdf
When i try to open the article, i get an error dialog box.
The error is
Unable to open document
Unhandled MIME type: “text/plain”
I am using
Linux SUJITH 2.6.20-16-generic #2 SMP Wed May 23 01:46:23 UTC 2007 i686 GNU/Linux
and my pdf reader is
Evince 0.8.1 Using poppler 0.5.4 (cairo)
Sujith
Whatever article i save as pdf, the file name is always read-articles.pdf
When i try to open the article, i get an error dialog box.
The error is
Unable to open document
Unhandled MIME type: “text/plain”
I am using
Linux SUJITH 2.6.20-16-generic #2 SMP Wed May 23 01:46:23 UTC 2007 i686 GNU/Linux
and my pdf reader is
Evince 0.8.1 Using poppler 0.5.4 (cairo)
Sujith
Last edited by werty37, 2007-07-03 15:55
2007-07-03 15:55
Hi fbliss,
try to use a print style sheet for printing articles as PDF. DOMPDF tries to translate all CSS commands compiling a page and it probably does not work with complex style sheets which are actually for screen display.
Regards
Leo
try to use a print style sheet for printing articles as PDF. DOMPDF tries to translate all CSS commands compiling a page and it probably does not work with complex style sheets which are actually for screen display.
Regards
Leo
2007-07-03 16:01
Hi fbliss.
Did you ever have a resolution to this? Started playing with the PDF generator and I get this issue. My site Stylesheets are all set to screen and I have a print one created. Even happens with all style sheets removed.
Thanks in advance!
Evan
Did you ever have a resolution to this? Started playing with the PDF generator and I get this issue. My site Stylesheets are all set to screen and I have a print one created. Even happens with all style sheets removed.
Thanks in advance!
Evan
Last edited by bumforaliving, 2009-01-14 08:06
Evan
2009-01-14 08:04
Hi Evan,
It has been so long, I don't recall! If you have tried (unsucessfully the print style sheet) I'm not sure what the next angle of attack might be. Could you post your print CSS code up for me to see?
Regards,
Fred
It has been so long, I don't recall! If you have tried (unsucessfully the print style sheet) I'm not sure what the next angle of attack might be. Could you post your print CSS code up for me to see?
Regards,
Fred
Come to the light... Typolight.
2009-02-01 05:39
Thanks for the reply Fred.
So you got it working?
Thing is, I don't think the issue is in the stylesheets. I removed ALL my
style sheets and even the ones the system includes (system/iefixes.css,
system/typolight.css,plugins/slimbox/css/slimbox.css) and it still happens.
It happens on my local windows box & my FreeBSD hosted account.
Could it be something in the DOMPDF code that you changed?
Here is an example page:
http://taganized.com/index.php/news-reader/items/test.165.html
Print style sheet:
http://taganized.com/Envision_Print.css
(From the output, it does not appear to be using it anyway compared to a
print preview.)
The others:
http://taganized.com/Envision_Global.css
http://taganized.com/Envision_Layout.css
http://taganized.com/Envision_Main.css
http://taganized.com/Envision_Menu.css
http://taganized.com/Envision_Right.css
http://taganized.com/Envision_Tags.css
I really appreciate what ever you can do to help me get this working. I have
not seen anyone else complain nor find reference to the issue on the web. =/
So you got it working?
Thing is, I don't think the issue is in the stylesheets. I removed ALL my
style sheets and even the ones the system includes (system/iefixes.css,
system/typolight.css,plugins/slimbox/css/slimbox.css) and it still happens.
It happens on my local windows box & my FreeBSD hosted account.
Could it be something in the DOMPDF code that you changed?
Here is an example page:
http://taganized.com/index.php/news-reader/items/test.165.html
Print style sheet:
http://taganized.com/Envision_Print.css
(From the output, it does not appear to be using it anyway compared to a
print preview.)
The others:
http://taganized.com/Envision_Global.css
http://taganized.com/Envision_Layout.css
http://taganized.com/Envision_Main.css
http://taganized.com/Envision_Menu.css
http://taganized.com/Envision_Right.css
http://taganized.com/Envision_Tags.css
I really appreciate what ever you can do to help me get this working. I have
not seen anyone else complain nor find reference to the issue on the web. =/
Evan
2009-02-01 16:51
Hi Evan,
Okay, so what I believe is happening is that the new line character is invalid. I thought this was an issue TL code that was fixed a long time ago, but you are on a windows server and I'm not sure put perhaps that is part of the issue (since newline characters can vary). It is certainly outputting the content correctly but we need to look into that.
For example, on line 940 of Controller.php you will see the TCPDF code does something like this:
So, the only recommendation I have for you is to do some research on this first on DOMPDF site and if nothing there then look into general newline character info for windows systems versus linux systems.
Good luck!
Okay, so what I believe is happening is that the new line character is invalid. I thought this was an issue TL code that was fixed a long time ago, but you are on a windows server and I'm not sure put perhaps that is part of the issue (since newline characters can vary). It is certainly outputting the content correctly but we need to look into that.
For example, on line 940 of Controller.php you will see the TCPDF code does something like this:
Code:
$strArticle = str_replace(array("\n", "\t"), '', $strArticle);
So, the only recommendation I have for you is to do some research on this first on DOMPDF site and if nothing there then look into general newline character info for windows systems versus linux systems.
Good luck!
Come to the light... Typolight.
2009-02-01 17:31
That would likely have been the explanation for my local development machine, but the site I sent you to above is a linux box.
Not sure why (as I had compltely removed ALL stylesheets
) but editing my print stylesheet I had:
line-height:1.4;
which I got from looking at the typolight.com print stylesheet.
Removed that line and the issue went away. I guess without an em,px,%... it defaulted to 0 height?
Nothing else is formatting right but at least I have a start!
Thanks for your help.
Not sure why (as I had compltely removed ALL stylesheets
line-height:1.4;
which I got from looking at the typolight.com print stylesheet.
Removed that line and the issue went away. I guess without an em,px,%... it defaulted to 0 height?
Nothing else is formatting right but at least I have a start!
Thanks for your help.
Evan
2009-02-01 20:38
