I have a government client that requires the legal 'section symbol' (§) in their documents. When creating the documents in a web page, this symbol is created with § or §.
I can not figure out how to get either of these to work in a pdf document created with FPDF. I have tried the iconv and utf8_decode methods, but neither have worked. Any ideas?
You're looking for html_entity_decode().
There is an easier approach to do this:
You can generate a section symbol using FPDF with using ascii code: chr(167).
It's good practice to make this a constant. At the top of your script, add:
define('SECTION',chr(167));
Now you can use SECTION in your script to print the euro symbol.
For example:
echo SECTION.'1.1';
Will output: §1.1
Note: This will also work for other symbols with chr(ascii), where ascii is the ascii code of the symbol. You can find an overview of ascii codes on this page: http://www.atwebresults.com/ascii-codes.php?type=2
Related
I have an existing program (codes) to generate PDF file via TCPDF. It works fine even contain non-English characters in most cases, but now, when the content has either two simplified Chinese characters 喆 (unicode number: 21894) or 旻 (unicode number: 26107), all Chinese characters will be converted to rectangle (invalid character).
I tried to check the uni2cid_ag15.php, and I can find the mapping of those two words and the mapped cids are correct. Is anyone know the reason for converting the Chinese characters incorrectly with that specific character(s)?
References:
https://raw.githubusercontent.com/adobe-type-tools/cmap-resources/master/cmapresources_gb1-5/cid2code.txt
https://github.com/tecnickcom/TCPDF/blob/master/fonts/uni2cid_ag15.php
Thanks for the advice in advance.
I found out the solution by using new encoding "GB18030" for php function mb_convert_encoding, instead of "GB2312". Those characters can be generated in the PDF without problem.
I am translating with poedit. However poedit seems to be ignoring apostrophes. For example shouldn't is coming through as shouldnt. I am encoding in utf-8. Does anyone know why this is the case and if there is a solution ?
I assure you that Poedit isn't somehow ignoring or eating apostrophes — that's preposterous. It's just an editor that puts whatever you wrote, exactly as you wrote it (yes, including ' or any Unicode characters), into your PO and MO files.
Your problem is in your PHP code where you incorrectly escape the (translated) strings before printing them — how and in what context you do that is unfortunately something you didn't share.
But this is why e.g. WordPress has functions like esc_attr_e that do any necessary escaping and do it correctly, so that you don't have to do anything ridiculous (and painful to work with!) like substituting ' with ’ in all your translations (which wouldn't even work when using untranslated text…).
You need to use the html entity: ’
Source: http://geektnt.com/tag/poedit
Some text characters need to be converted into html entities otherwise they will not display correctly. A very common example is a word containing an apostrophe or single quote (‘) which needs to be replaced with ’ — for example, Chloe O’Brian should be written as Chloe O’Brian. For a complete list of html entities, visit W3Schools.
The following Symbols prints well in an MS Excel spreadsheet when outputting using VBA:
Sub print_chrw_sub()
Dim a1
a1 = "&H27E6"
ActiveCell.Offset(1).Value = ChrW(a1)
Dim a2
a2 = "&H27E7"
ActiveCell.Offset(2).Value = ChrW(a2)
End Sub
Output:
⟦
⟧
However, when I am using the symbols in a PHP code, the sybols look like square blocks within the code as well as on a web browser - also in the current usage above. Example:
<?php
echo $str1 = "⟧"
?>
I am using UTF-8 encoding.
On the flip side the following sybols are printing correctly in PHP code as well as on a web browser:
chrW(&H22A4)
Output:
⊤
chrW(&H22A5)
Output:
⊥
Thanks for any help.
The character you refer as chrW(&H27E7) is known as the Mathematical right white square bracket (or U+27E7).
When it is displayed in Excel, the font displayed is probably Calibri or Arial, but these fonts actually don't support this character.
And that's where font substitution steps in: to provide a font wich will correctly handle the character.
If you look at this page, you will see which fonts on your system actually support U+27E7. On my system there is only two: Cambria Math and Segoe UI Symbol.
If you see a square symbol (□), it means that font substitution didn't work correctly. For the PHP source, it is not very important, because the correct character will actually be there (provided the encoding is set up correctly).
For the HTML code, you should consider setting a font which you know support this character, be keep in mind that local fonts (the ones installed) differ vastly between two systems. You may want to use the CSS font-face to provide a web font.
Im developing a PDF generation script with PHP, using FPDF library, its all fine for text and images, but when I put corrency symbols like Pound or Euro, it is giving some special symbols instead, I could solver the same in normal pages by setting character encoding of the webpage, but not sure how to set character encoding for a PDF document.
You are running into encoding - decoding issues.. Add this line on top of your script.
<?php
header('Content-Type: text/html;charset=utf-8');
followed by your FDPF generation code.
i have tried to copy euro symbol from Wikipedia...and echo it (in my parent page),at that time it is working.but when i replace the same html content using jquery(used same symbol to echo in the other page).it is not displaying.why is it so..(or is der any way to display the same thing using html)?
In HTML you do this
€
And of course this works with jQuery, or any other web based language you are using
For more information look here
You need to ensure that your data is encoded using $X, that your server claims it is encoded using $X, and that any meta tags or xml prologs you may have also claim it is encoded using $X.
... where $X is a character encoding which includes the euro symbol. UTF-8 is recommended.
The W3C have an introduction to character encoding.
You can bypass this using HTML entities (€ in this case), which let you represent characters using ASCII (which is a subset of pretty much any character encoding you care to name). This has the advantage of being easy to type of a keyboard which doesn't have that character, but requires a tiny bit more bandwidth and will make it hard to read the source code of documents which include a lot of non-ASCII characters.
Note that HTML entities will only work when dealing with HTML. You'll find it breaking if you try things such as $(input).val('€').