I'm trying to render some "special characters" (⇒⇀↛←⇐⇐↼↚↔⇔⇌⇄⥄) on a new page. When I use the custom TTF "Noto Sans Regular" most of the characters don't render, if I simply swap the font to "Symbola" everything renders exactly as you'd expect.
Is this a known issue in ZendPDF (2.0.2) or am I doing something wrong?
It turns out that the NotoSans font only contained a subset of the characters... lesson learned!
Related
I am trying to export to PDF using FPDF and TCPDF php library. I found that the emojis like 😁 😀 💃🏻 ❤️ 🥳 where not converted. Only ️️some rectangle box there in generated pdf. I also tried tfpdf.
$text = "There is my text 😁 , 😀 and emojis 💃🏻 ❤️ 🥳";
require('tfpdf/tfpdf.php');
$pdf = new tFPDF();
$pdf->AddPage();
//Add a Unicode font (uses UTF-8)
$pdf->AddFont('Segoe UI Symbol','','seguisym.ttf',true); // DejaVuSans.ttf
$pdf->SetFont('Segoe UI Symbol','',12);
$pdf->Write(8,$text);
$pdf->Output();
I also tried different font. But didn't work for me. Can any one help me in this regard?
Sadly fPDF, TCPDF nor tFPDF can't print those characters. Issue is, these characters are not part of BMP, they are expressed with surrogate pairs, meaning they behave like multiple characters in UTF-16 (because of that one emoticon is printed as 2 rectangle boxes, not one) and also they have codepoint above 65535. However all mentioned PDF libraries relies on codepoint index being <= 65535 as well as TFontFile class reading TTF files.
You would also need to add TTF file having complete set of Unicode charset, or at least emoticons. Most fonts does not have it. This brings another issue for PDF library, which would probably need to have support for fallback font, which will be used when codepoint is not found in main font (for example you want to print text in Gotham, but since that does not include emoji, use other font for them). Btw for example emoji font "Noto Color Emoji" has 23 MB TTF file. So it gets big easily.
Anyway, all of the above can be added to PDF libraries, but it will require some effort. I am planning to do it for my needs as well sometimes. I think it will take roughly 1 man day.
Alternativelly, you might try something more robust like mPDF, but that library is huge, slow and require complete rewrite of your fPDF code. Also can't guarantee it can print emojis as well.
I'm having a problem with rendering a string of text that contains half-width kana in a PDF. It considers the half-width kana to be full-width so it turns out something like this:
This is my code snippet:
PDF::Cell(15, 6, '商品ｺｰﾄﾞ', 1, 0, 'C', 0, '', 0);
I'm also using the cid0jp font provided in TCPDF to display Japanese characters:
PDF::SetFont('cid0jp', 'B', 9);
In the end, I want it to maintain the half-width katakana to fit the cell and remove unnecessary spaces.
TCPDF Library used: https://tcpdf.org/
When you use the cid0jp font you're leaving the font rendering up to the PDF reader which can introduce differences in rendering between different readers and operating systems. The spacing differences can be pretty major, but I'm not sure if that's an issue with TCPDF's implementation or just a consequence of relying on the reader to provide the font.
Below, I've included an example comparing Microsoft Edge and Foxit Reader rendering of that text in cid0jp. I also included the full-width versions on the second line. Edge came a little closer on the spacing for half-widths than Foxit. Google Drive's PDF preview did the same thing as Foxit did with the additional spacing around the half-widths.
Since the space you're working with there is so tight, it might be worth embedding a specific font into the document. In my tests that was a lot more reliable as far as rendering went. (I've also included screenshots of that test below. Make sure subsetting is on if you don't want the entire font included in each file.)
Just in case you might not know how to do that:
$embfont = TCPDF_FONTS::addTTFfont('/Path/to/font.ttf', 'TrueTypeUnicode', '', 32);
$pdf->setFont($embfont, '', '9');
$pdf->Cell(15,6,'商品ｺｰﾄﾞ',1,0,'C',0,'',0);
Examples with cid0jp:
Examples with embedded font:
(Admittedly, this font isn't very good at small sizes.)
So I have a problem with diacritics in wordpress.This is the website http://colectia-harnau.ro This is the div for first category:
<div style="font-family: 'Sancreek', cursive;font-size:110%;">
SUPORTURI PREZENTARE
</div>
As you can see on google fonts, this font have diacritics like ă,ș,ț etc. Here is the font URL: https://www.google.com/fonts/specimen/Sancreek
As you can see here the diacritics are loaded but showed with different font
Any ideas? Thanks
Make sure you are using the extended latin character sets. Like this:
<link href='http://fonts.googleapis.com/css?family=Sancreek&subset=latin,latin-ext' rel='stylesheet' type='text/css'>.
Note the latin-ext
Ok , problem solved!
For those who will occur this issue. You need to select the Larin extended option from 2nd selector!
Latin Extended (latin-ext)
I'm using TCPDF to create PDFs that include Japanese characters. Using the TrueType font ArialUni, most characters are displayed correctly, except the yen symbol shows up as a square box instead of ￥.
Here's a snippet of the resulting PDF using ArialUni:
So I tried another font. Here's the same section of the resulting PDF using GT200001:
And here's the same section using Helvetica:
Here's the same section using GNU's FreeSans:
I would like that second line to show up as "(渋谷猿, ¥8,000)"
I'm not surprised that Helvetica and Freesans cannot render the kanji correctly, but I cannot fathom why the other two fonts can render the kanji, but not the yen symbol, which is much more common.
The web server creating the PDFs is LAMP running Ubuntu. I'm viewing the PDFs on OS X with Chrome (using its in-browser view). I've also tried downloading the PDFs with Firefox and displaying in Preview. I get essentially the same results: ArialUni and GT200001 don't display the yen symbol, while Helvetica and Freesans don't display the kanji (but do display the yen symbol).
I know I can use different fonts for different lines/cells of the PDF, but the kanji and yen symbol are on the same line.
How can I get the kanji and yen symbol to display in a single line using TCPDF?
Near the top of my PDF code, I load the font using TCPDF's addTTFfont();
$this->font = $this->addTTFfont(K_PATH_FONTS.'arialuni.ttf', 'TrueTypeUnicode', '', 32);
Here's the code I'm using to write the section of the PDF.
$pdf->SetFont('arialuni','',10);
$pdf->MultiCell(105, $remarks_height, $remarks, 'B', 'L', false, 0, '', '', true, 1, false, true, $remarks_height, 'T');
In this wikipedia article you can read some more about this character.
Basically, there are 2 different ways of writing this Japanese Kanji, as it happens with some other symbols. From accepted answer "I was using ¥, not ￥", we can see that he was using the 'occidental' or Unicode ¥ symbol, when he actually wanted to use the double-width character ￥.
Oh dear, I figured it out.
I was using ¥, not ￥. Sorry for being confused!!
What I have noticed with TCPDF is, it's all about fonts.
I tried to use it for 15 totally different languages with different writing style too and only font I am using is Arial UNICODE MS.
TCPDF has function which will convert that font into TCPDF friendly files, which are arialuni.ctg.z(70k), arialuni.php(447k), and arialuni.z (14M).
the functions are,
http://www.tcpdf.org/fonts.php
$fontname = $pdf->addTTFfont('/path-to-font/ARIALUNICODE.TTF', 'TrueTypeUnicode', '', 32);
I'm using imagettftext to generate images from OpenType files. Everything works until I try to use an accented character (e.g. å) or a character such as √. In their place I get the .notdef glyph.
The fonts I'm using definitely have these characters. To make things even more frustrating, when I use a TTF everything works as expected.
Any ideas?
Thanks
Sorry to tell you, but PHP OTF supports only standard Ascii characters. It's a well known fact that special characters in OTF only very rarely work. I'm afraid you will have to stick with TTF until they correct that.
Not true! (answer 1) imagettftext works with unicode. Some font files do not have accented characters but rely on the graphic library to use the unicode combining diacritical marks (0300–036F) to draw the character correctly. This seems to fail in php gd.