I ran into an odd problem with TCPDF 6.0.002 and Firefox's (19.0.2) internal PDF-viewer when using an unicode TTF of Frutiger 45/55/65 (the "standard"-version Win/TT from http://www.linotype.com/de/469/Frutiger-family.html) and I'm not sure if the problem is Firefox, TCPDF, the font or some combination of all three:
Adobe Reader X (10.1.6) and Chrome's internal PDF-renderer show this text as expected.
The problem:
The internal PDF-Renderer in Firefox does not show any/enough space(s) between some chars like the ampersand, the dollar- and the percentage-char. The percentage-char and the ampersand even collide. Other "special" chars (§, /, (, ), =, ?) do have a correct spacing behind them:
First of all this seemed to be a bug in Firefox, but while trying different things I found some oddities:
1. If I don't set a specific font, everything is fine in both viewers - so here it looks like the problem is the font or its conversion.
2. If I import/add the font file as "TrueType" instead of "TrueTypeUnicode" (or just change $type in the PHP font-file accordingly), the spacings are correct in both viewers. Next odd thing here: Adobe Reader neither shows the german "umlauts" ä, ö and ü nor the sz-ligature ß - which is to be expected because of a wrong encoding (ISO-8859 vs. UTF-8). Surprisingly Firefox does show these chars...
3. If I run my testscript in FPDF 1.7 (with slight syntactic changes to the TCPDF syntax) - importing the font there and converting the string from UTF-8 to ISO-8859-1 with iconv() - there are no problems with missing spaces or umlauts. So here it seems this problem is somehow specific to some changes/additions in TCPDF?
I'm using a german Windows 7 x64 if that matters in some way.
Any suggestions?
Last edit: cpw 2013-03-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can confirm this, not only in FireFox but also in Safari and Chrome in my case. Some of it was fixed in 6.0003 but it's still far from ideal. Try the euro sign for instance, same thing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some other testing to make things even more weird: ;-)
Frutiger 55 (Roman) is OK - of the three Frutiger fonts I own, only 45 (Light) and 65 (Bold) are having the space-problems in Firefox.
I converted my Windows 7 Arial - everything is fine with that.
If I use http://www.xml-convert.com/en/convert-tff-font-to-afm-pfa-fpdf-tcpdf to convert Frutiger 45 (resulting in a .afm-file instead of a .ctg.z next to the .z- and .php-file), it's fine. If I convert Frutiger 55 here, there's a space missing behind the dollar char - in Firefox and Adobe Reader.
Furthermore I'd like to try some other commercial fonts I own, like Neue Helvetica 35 and 45, but they are in OpenType-(.otf-)Format. On the one hand http://www.tcpdf.org/fonts.php states that OpenType is supported, on the other hand the docs for addTTFFont() ( http://www.tcpdf.org/doc/code/classTCPDF.html#a471562985997be1573d387f0aeae6964 ) do not mention OpenType - if I run addTTFfont() on an .otf-file, it finishes without any error message, but the result is just a .z File, the CIDToGIDMap (.ctg.z) and the font definition PHP-file are missing and I can't use the font.
// EDIT: I just noticed there's a version .004 now - I'll give that a try.
// EDIT 2: No, still the same.
Last edit: cpw 2013-03-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems to have something to do with $type = 'TrueType' vs. $type = 'TrueTypeUnicode'.
I compared the TCPDF generated font-PHP-file to the one generated by xml-convert.com. Next to some different contents in $desc and $cw the type is "TrueType" instead of "TrueTypeUnicode" and $enc is set to "cp1252". Setting this in the TCPDF generated file nearly works - now it's just the Euro-sign € that has no space behind it, in Firefox as well as in Chrome and Adobe Reader.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem with OpenType fonts is that they are not supported, unless they're in TrueType format. The OpenType standard does not specify the outline data format. Rather, it accommodates any of several existing standards. Sometimes terms like "OpenType (PostScript flavor)", "Type 1 OpenType", "OpenType CFF", or "OpenType (TrueType flavor)" are used to indicate which outline format a particular OpenType font file contains. Only the OpenType TrueType flavor is supported by TCPDF, rendering the use of OpenType fonts next to useless.
The reason why the addTTFFont function returns nothing can be found here: https://sourceforge.net/p/tcpdf/bugs/787/ It's becuase you are using a CFF font. The first 4 characters in a OpenType CFF font are 'OTTO', you can recognise them by that.
I've noticed that even some TrueType fonts are not supported by TCPDF, that's why I always convert my fonts to PFB/AFM first and then use them in TCPDF. Annoying, but so... At least this works.
The Euro sign thingy, that's a bug for sure. The encoding tables used in TCPDF are the cause of that I think.
Last edit: Liam Vans 2013-03-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The results are a PFB- an an AFM-file. Processing the PFB-File with addTTFfont() (regardless if $fonttype left blank for auto detection or explicitly set to Type1) gives me a notice:
creates a .z- and a broken PHP-font-description-file:
<?php// TCPDF FONT FILE DESCRIPTION$type='Type1';$name='FrutigerLT45Light';$up=-75;$ut=50;$dw=-35;$diff='';$enc='cp1252';$file='frutiger45conv.z';$size1=6042;$size2=46490;$desc=array('Flags'=>32,'FontBBox'=>'[-31 -250 1000 911]','ItalicAngle'=>0,'Ascent'=>911,'Descent'=>-250,'Leading'=>0,'CapHeight'=>720,'XHeight'=>0,'StemV'=>70,'StemH'=>55,'AvgWidth'=>-35,'MaxWidth'=>75,'MissingWidth'=>);$cw=array(0=>,1=>,2=>,3=>,4=>,5=>,6=>,7=>,8=>,9=>,10=>,11=>,12=>,13=>,14=>,15=>,16=>,17=>,18=>,19=>,20=>,21=>,22=>,23=>,24=>,25=>,26=>,27=>,28=>,29=>,30=>,31=>,32=>,33=>,34=>,35=>,36=>-5,37=>-15,38=>-92,39=>,40=>,41=>,42=>,43=>,44=>,45=>,46=>,47=>,48=>,49=>,50=>,51=>,52=>,53=>,54=>,55=>,56=>,57=>,58=>,59=>,60=>,61=>,62=>,63=>,64=>41,65=>-92,66=>,67=>-92,68=>-92,69=>,70=>,71=>-37,72=>-92,73=>,74=>,75=>,76=>,77=>13,78=>-92,79=>-37,80=>,81=>-37,82=>-9,83=>,84=>,85=>-92,86=>,87=>-71,88=>,89=>,90=>,91=>,92=>,93=>,94=>,95=>,96=>,97=>,98=>,99=>,100=>,101=>,102=>,103=>,104=>,105=>,106=>,107=>,108=>,109=>74,110=>,111=>,112=>,113=>,114=>,115=>,116=>,117=>,118=>,119=>19,120=>,121=>,122=>,123=>,124=>,125=>,126=>,127=>,128=>,129=>,130=>,131=>,132=>,133=>-15,134=>,135=>,136=>,137=>-15,138=>,139=>,140=>13,141=>,142=>,143=>,144=>,145=>,146=>,147=>,148=>,149=>,150=>,151=>-15,152=>,153=>-25,154=>,155=>,156=>13,157=>,158=>,159=>,160=>,161=>,162=>-9,163=>,164=>,165=>,166=>,167=>,168=>,169=>41,170=>,171=>,172=>,173=>,174=>41,175=>,176=>,177=>,178=>,179=>,180=>,181=>,182=>,183=>,184=>,185=>,186=>,187=>,188=>75,189=>75,190=>75,191=>,192=>-92,193=>-92,194=>-92,195=>-92,196=>-92,197=>-92,198=>13,199=>-92,200=>,201=>,202=>,203=>,204=>,205=>,206=>,207=>,208=>-92,209=>-92,210=>-37,211=>-37,212=>-37,213=>-37,214=>-37,215=>,216=>-37,217=>-92,218=>-92,219=>-92,220=>-92,221=>,222=>,223=>,224=>,225=>,226=>,227=>,228=>,229=>,230=>74,231=>,232=>,233=>,234=>,235=>,236=>,237=>,238=>,239=>,240=>,241=>,242=>,243=>,244=>,245=>,246=>,247=>,248=>,249=>,250=>,251=>,252=>,253=>,254=>,255=>);
without a closing PHP-Tag (?>), so it seems to stop outputting at some point.
Next I tried FontForge, opening my TTF and generating it as PS Type 1 (Binary):
Your font has a 2 byte encoding, but you are attempting to save it in a format that only supports one byte encodings. This means that you won't be able to access anything after the first 256 characters without reencoding the font.
The resulting PFB-file imports without any notices, the PDF-Result is as in the attached screenshot.
The only other FontForge output format with a PFB-extension is PS Type 1 (Multiple). While creating it asks for a "sub font definition file", whatever that might be.
Funny thing: I can't find another TTF having the problem with missing spaces... I also used FreeFontConverter.com to convert my other Linotype-OTF-Fonts (Neue Helvetica 35 & 45, Trade Gothic Light) to TTF and imported them - no problems here.
The missing spaces can be solved by adding them to the translation tables. Sometimes character 32 is set als 'null' or 'nbrspace'. Change that to 'space' and that'll solve that issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, definitively doesn't work and does exactly the same thing as before: a notice and a broken PHP-file with missing values as a description. I also tried this with various other converted TTFs, it's always the same.
Anyway it seems I found a solution:
I compared the generated PHP-files of Frutiger 45 (doesn't work properly) and 55 (works fine): I noticed that the value of 0 in the $cw-array is 500 in Frutiger 45, 278 in Frutiger 55. So I changed this value to 278 in Frutiger 45 - now there are spaces where they belong.
Although I don't really get what's happening there - in what way does the NUL-value have an influence on spaces after exactly four characters (35 to 38)? And why only in Firefox?
Last edit: cpw 2013-03-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I ran into an odd problem with TCPDF 6.0.002 and Firefox's (19.0.2) internal PDF-viewer when using an unicode TTF of Frutiger 45/55/65 (the "standard"-version Win/TT from http://www.linotype.com/de/469/Frutiger-family.html) and I'm not sure if the problem is Firefox, TCPDF, the font or some combination of all three:
First of all I converted my TTFs with addTTFfont:
Example-script:
require('./tcpdf/tcpdf.php'); $pdf = new TCPDF($orientation = "P", $unit = "mm", $format = "A4", $unicode = true, $encoding = 'UTF-8', $diskcache = false, $pdfa = false); $pdf->setFontSubsetting(false); // Required for Firefox; it doesn't seem to like font-subsetting $pdf->AddFont("frutiger45","","frutiger45.php"); $pdf->AddPage("P", "A4"); $pdf->SetXY(19.8, 110, true); $pdf->SetTextColor(000, 000, 000); $pdf->SetFont("frutiger45","","10"); $pdf->Cell($width = 32, $height = 3.1, $text = "This is text in Frutiger 45 äöüß & something ! ' § $ % & / ( ) = ? abcd", $border = 0, $ln = 1, $align = "L"); $pdf->Output();(The PHP-source's encoding is UTF-8)
Adobe Reader X (10.1.6) and Chrome's internal PDF-renderer show this text as expected.
The problem:
The internal PDF-Renderer in Firefox does not show any/enough space(s) between some chars like the ampersand, the dollar- and the percentage-char. The percentage-char and the ampersand even collide. Other "special" chars (§, /, (, ), =, ?) do have a correct spacing behind them:
First of all this seemed to be a bug in Firefox, but while trying different things I found some oddities:
1. If I don't set a specific font, everything is fine in both viewers - so here it looks like the problem is the font or its conversion.
2. If I import/add the font file as "TrueType" instead of "TrueTypeUnicode" (or just change $type in the PHP font-file accordingly), the spacings are correct in both viewers. Next odd thing here: Adobe Reader neither shows the german "umlauts" ä, ö and ü nor the sz-ligature ß - which is to be expected because of a wrong encoding (ISO-8859 vs. UTF-8). Surprisingly Firefox does show these chars...
3. If I run my testscript in FPDF 1.7 (with slight syntactic changes to the TCPDF syntax) - importing the font there and converting the string from UTF-8 to ISO-8859-1 with iconv() - there are no problems with missing spaces or umlauts. So here it seems this problem is somehow specific to some changes/additions in TCPDF?
I'm using a german Windows 7 x64 if that matters in some way.
Any suggestions?
Last edit: cpw 2013-03-21
I can confirm this, not only in FireFox but also in Safari and Chrome in my case. Some of it was fixed in 6.0003 but it's still far from ideal. Try the euro sign for instance, same thing.
I just switched to .003 and re-added/-converted the fonts - no changes here.
For me the problem neither occurs in Chrome (25.0.1364.172 m) nor in Safari (5.1.7 (7534.57.2)) - the €-sign in Firefox is OK as well...
I also narrowed the problematic characters down: From all characters on my (german) keyboard it's just
# $ % &
all the others seem to be OK.
Which leads me to a pattern:
Theses characters are direct "neighbours" in http://en.wikipedia.org/wiki/ISO/IEC_8859-15#Codepage_layout as well as http://en.wikipedia.org/wiki/UTF-8#Codepage_layout :
# 0x0023 (35 Decimal)
$ 0x0024 (36 Decimal)
% 0x0025 (37 Decimal)
& 0x0026 (38 Decimal)
...although I'm not sure what to make of that.
Last edit: cpw 2013-03-21
Is the doument working witht the default fonts?
Additionally, are you sure that all characters are correctly encoded in UTF-8?
Last edit: Nicola Asuni 2013-03-21
First I tried setting no font at all, now I also tried
$pdf->SetFont("dejavusans","","10");$pdf->SetFont("freemono","","10");$pdf->SetFont("helvetica","","10");$pdf->SetFont("freesans","","10");Everything is perfectly fine with these fonts.
Yes - I'm using an Eclipse-setup with all editors set to UTF-8. If the source-encoding was wrong, it should fail en-/decoding ä,ö,ü and ß.
Last edit: cpw 2013-03-21
Some other testing to make things even more weird: ;-)
Frutiger 55 (Roman) is OK - of the three Frutiger fonts I own, only 45 (Light) and 65 (Bold) are having the space-problems in Firefox.
I converted my Windows 7 Arial - everything is fine with that.
If I use http://www.xml-convert.com/en/convert-tff-font-to-afm-pfa-fpdf-tcpdf to convert Frutiger 45 (resulting in a .afm-file instead of a .ctg.z next to the .z- and .php-file), it's fine. If I convert Frutiger 55 here, there's a space missing behind the dollar char - in Firefox and Adobe Reader.
Furthermore I'd like to try some other commercial fonts I own, like Neue Helvetica 35 and 45, but they are in OpenType-(.otf-)Format. On the one hand http://www.tcpdf.org/fonts.php states that OpenType is supported, on the other hand the docs for addTTFFont() ( http://www.tcpdf.org/doc/code/classTCPDF.html#a471562985997be1573d387f0aeae6964 ) do not mention OpenType - if I run addTTFfont() on an .otf-file, it finishes without any error message, but the result is just a .z File, the CIDToGIDMap (.ctg.z) and the font definition PHP-file are missing and I can't use the font.
// EDIT: I just noticed there's a version .004 now - I'll give that a try.
// EDIT 2: No, still the same.
Last edit: cpw 2013-03-22
It seems to have something to do with $type = 'TrueType' vs. $type = 'TrueTypeUnicode'.
I compared the TCPDF generated font-PHP-file to the one generated by xml-convert.com. Next to some different contents in $desc and $cw the type is "TrueType" instead of "TrueTypeUnicode" and $enc is set to "cp1252". Setting this in the TCPDF generated file nearly works - now it's just the Euro-sign € that has no space behind it, in Firefox as well as in Chrome and Adobe Reader.
The problem with OpenType fonts is that they are not supported, unless they're in TrueType format. The OpenType standard does not specify the outline data format. Rather, it accommodates any of several existing standards. Sometimes terms like "OpenType (PostScript flavor)", "Type 1 OpenType", "OpenType CFF", or "OpenType (TrueType flavor)" are used to indicate which outline format a particular OpenType font file contains. Only the OpenType TrueType flavor is supported by TCPDF, rendering the use of OpenType fonts next to useless.
The reason why the addTTFFont function returns nothing can be found here: https://sourceforge.net/p/tcpdf/bugs/787/ It's becuase you are using a CFF font. The first 4 characters in a OpenType CFF font are 'OTTO', you can recognise them by that.
I've noticed that even some TrueType fonts are not supported by TCPDF, that's why I always convert my fonts to PFB/AFM first and then use them in TCPDF. Annoying, but so... At least this works.
The Euro sign thingy, that's a bug for sure. The encoding tables used in TCPDF are the cause of that I think.
Last edit: Liam Vans 2013-03-22
Not for me I'm afraid... What converter do you use for that?
My first attempt was ttf2pt1 from the GnuWin32-package ( http://gnuwin32.sourceforge.net/packages/ttf2pt1.htm ) called with the b-Option:
The results are a PFB- an an AFM-file. Processing the PFB-File with addTTFfont() (regardless if $fonttype left blank for auto detection or explicitly set to Type1) gives me a notice:
creates a .z- and a broken PHP-font-description-file:
without a closing PHP-Tag (?>), so it seems to stop outputting at some point.
Next I tried FontForge, opening my TTF and generating it as PS Type 1 (Binary):
The resulting PFB-file imports without any notices, the PDF-Result is as in the attached screenshot.
The only other FontForge output format with a PFB-extension is PS Type 1 (Multiple). While creating it asks for a "sub font definition file", whatever that might be.
// EDIT:
Also no luck with http://www.freefontconverter.com, http://www.files-conversion.com/font-converter.php and http://onlinefontconverter.com. Either addTTFFont() returns FALSE or I end up with nearly no spaces at all (see attachment).
Funny thing: I can't find another TTF having the problem with missing spaces... I also used FreeFontConverter.com to convert my other Linotype-OTF-Fonts (Neue Helvetica 35 & 45, Trade Gothic Light) to TTF and imported them - no problems here.
Last edit: cpw 2013-03-24
I use ttf2pt1 also, try this:
ttf2pt1 -l latin1 -F -b "D:\frutiger45.ttf"
The missing spaces can be solved by adding them to the translation tables. Sometimes character 32 is set als 'null' or 'nbrspace'. Change that to 'space' and that'll solve that issue.
No, definitively doesn't work and does exactly the same thing as before: a notice and a broken PHP-file with missing values as a description. I also tried this with various other converted TTFs, it's always the same.
Anyway it seems I found a solution:
I compared the generated PHP-files of Frutiger 45 (doesn't work properly) and 55 (works fine): I noticed that the value of 0 in the $cw-array is 500 in Frutiger 45, 278 in Frutiger 55. So I changed this value to 278 in Frutiger 45 - now there are spaces where they belong.
Although I don't really get what's happening there - in what way does the NUL-value have an influence on spaces after exactly four characters (35 to 38)? And why only in Firefox?
Last edit: cpw 2013-03-25
Did you try to convert the font using AddTTFFont and setting all the correct values for the Type1 font?
First I converted the TTF to PTB/AFM with ttf2pt1 like Liam suggested:
(I tried Arial coming with Windows 7 and several other TTFs to be sure the problems aren't caused by a potentially broken Frutiger-font)
My import script for the resulting PFB looks like this:
require('./tcpdf/tcpdf.php'); $pdf = new TCPDF("P", "mm", "A4"); var_dump($pdf->addTTFfont($fontfile="./fontimport/arial.pfb", $fonttype = 'Type1', $enc = '', $flags = 32, $outpath = '', $platid = 3, $encid = 1, $addcbbox = false));