I am using tcpdf to generate datamatrix barcodes. Works really nice. Now I was asked if we could add fnc1 characters to our code.
But I have no clue what the representation of the fnc1 character would be correct for the tcpdf generator.
I came across this here http://sourceforge.net/p/tcpdf/discussion/435311/thread/161b1b1a
But I would like to understand where the answer of using chr(241) actually comes from. To me it seems like it fell from the sky. Documentation doesn't say anything about it and I have not found anywhere else that chr(241) would be a representation of the fnc1 character.
Apart from that, it doesn't work for me, scanning the barcode just results in ñ characters in the middle of the code.
Anyone an idea how I could get the fnc1 character into my tcpdf datamatrix? What am I missing? Thanks for help in advance!
$string = chr(241).str_replace(";", chr(241), $string);
$barcodeobj = new TCPDF2DBarcode();
$barcodeobj->setBarcode($string, 'DATAMATRIX');
$barcodeobj->getBarcodeSVGcode(6, 6, 'black');
Looking at the code for version 1.0.008 (from 2014-05-06) in /tcpdf/include/barcodes/datamatrix.php I cannot see any comprehensive treatment of the special function or macro characters in Data Matrix so you are probably out of luck.
That said, the forum reply to which you link was written by the author of the TCPDF (Nicola Asuni) so it might we worth reaching out to him to see what he was thinking at the time. My guess would be that an example input used by some other library had mislead him into believing that FNC1 can be represented as an ordinary code point, however this is wrong since FNC1 is a non-data character that requires special treatment.
Related
I am writing php code that generates html that contains links to documents via their DOI. The links should point to https://doi.org/ followed by the DOI of the document.
As the results is a url, I thought I could simply use php's esc_url() function like in
echo '' . esc_url('https://doi.org/' . $doi)) . '';
as this is what one is supposed to use in text nodes, attribute nodes or anywhere else. Unfortunately things apparenty aren't that easy...
The problem is that DOIs can contain all sorts of special characters that are apparently not handled correctly by esc_url(). A nice example of such a DOI is
10.1002/(SICI)1521-3978(199806)46:4/5<493::AID-PROP493>3.0.CO;2-P
which is supposed to link to
https://doi.org/10.1002/(SICI)1521-3978(199806)46:4/5<493::AID-PROP493>3.0.CO;2-P
With $doi equal to this DOI the above code however produces a link that is displayed and links to https://doi.org/10.1002/(SICI)1521-3978(199806)46:4/5493::AID-PROP4933.0.CO;2-P.
This leads me to the question: If esc_url() is obviously not one-size-fits-all no-brained solution to escaping urls, then what should I use? For this case I can get the result I want with
esc_url(htmlspecialchars('https://doi.org/' . $doi))
but is this really the right way™ of doing it? Does this have any other unwanted side effects? If not, then why does esc_url() not also escape < and >? Would esc_html() be better than htmlspecialchars()? If so, should I nest it into a esc_url()?
I am aware that there are many articles on escaping urls in php on stackoverflow, but I couldn't find one that addresses the issues of < and > signs.
I'm no PHP expert, but I do know about DOIs and SICIs can be really annoying.
URL-encoding and HTML encoding are separate things, so it makes sense to think about them separately. You must escape the angle-brackets to make correct HTML. As for the URL-escaping, you should also do this because there are other characters that might break URLs (such as the # character, which also pops up from time to time).
So I would recommend:
'https://doi.org/' . htmlspecialcharacters(urlencode($doi))
Which will give you:
Click here
Note the order of function application, and the fact that you don't want to encode the https://doi.org resolver!
To the above "dipshit decision" comment... it's certainly inconvenient. But SICIs were around before DOIs and it's one of those annoying things we've had to live with ever since!
Encoding makes this a tough thing to explain. I'm getting a string from an XML file using PHP. When I echo it I see a small black circle: • or • . Oh, stackoverflow renders these, sorry. I meant to say it's the ascii character "bull" or "#8226"
echo $str;
gets me:
[CIRCLE] wordswords [CIRCLE] more words [CIRCLE] still more words
How can I find this character using PHP? I want to explode on it. I can't search for a circle, and searching for 8226 or circ doesn't work. Do I have to use urlencode?
$str=url_encode($str);
$str=str_replace(%E2%80%A2,'-CIRCLE-',$str);
$str=url_decode($str);
$str=explode('-CIRCLE-');
Or is there a more efficient way?
Check out this thread: Bullet "•" in XML. I think it will help your to find an answer.
I am using the PHP Library TCPDF. I am running into a small issue when using the MultiCell method and justification option. The last line of the paragraph justifies (I suppose does what it is supposed to) but only with a few words leaving large spaces in between. These are dynamic forms I am creating so MultiCell (instead of text or write) is needed.
Does anyone know if there is a way to prevent this from happening but still be able to use the MultiCell method? I have ran into weird issues in the past using writeHTML for things and want to avoid if possible.
Here is a sample of code producing the result:
$text = 'This is an example paragraph with no other meaning than to show what is currently happening with this justification issue. I really hope there is a way to keep the ';
$text .= 'justification, yet keep the last sentence from doing so and looking silly. Thank you all for your help and time, it is much appreciated.';
$this->_pdf->MultiCell(0, 0, $text, 0, 'J', false, 1);
Thank you very much for your time.
I don't think that there is a 'setting' to handle this; however, if you simply put a new line ("\n") at the end of your string it does exactly what I was looking for.
So if anyone is having a similar problem, the answer (in my case) is to simply add a new line.
$text = "...last line of the paragraph.\n";
I ran into a quirky syntax issue.
I am using php and cUrl to pull in data from a web page. The link has several variables. One of them is '<V', but the resulting link keeps translating '<V' as '<V', looking as '<' and the 'less than' symbol, when I need the literal text.
I have looked all over the place to figure out how to force php to read '<V' literally but have not found it.
Any ideas here would be appreciated.
Thanks.
You need to encode your HTML entities. Either use htmlentities or manually type out the string "<V".
I'm trying to scrape a price from a web page using PHP and Regexes. The price will be in the format £123.12 or $123.12 (i.e., pounds or dollars).
I'm loading up the contents using libcurl. The output of which is then going into preg_match_all. So it looks a bit like this:
$contents = curl_exec($curl);
preg_match_all('/(?:\$|£)[0-9]+(?:\.[0-9]{2})?/', $contents, $matches);
So far so simple. The problem is, PHP isn't matching anything at all - even when there are prices on the page. I've narrowed it down to there being a problem with the '£' character - PHP doesn't seem to like it.
I think this might be a charset issue. But whatever I do, I can't seem to get PHP to match it! Anyone have any ideas?
(Edit: I should note if I try using the Regex Test Tool using the same regex and page content, it works fine)
Have you try to use \ in front of £
preg_match_all('/(\$|\£)[0-9]+(\.[0-9]{2})/', $contents, $matches);
I have try this expression with .Net with \£ and it works. I just edited it and removed some ":".
(source: clip2net.com)
Read my comment about the possibility of Curl giving you bad encoding (comment of this post).
maybe pound has it's html entity replacement? i think you should try your regexp with some sort of couching program (i.e. match it against fixed text locally).
i'd change my regexp like this: '/(?:\$|£)\d+(?:\.\d{2})?/'
This should work for simple values.
'#(?:\$|\£|\€)(\d+(?:\.\d+)?)#'
This will not work with thousand separator like 234,343 and 34,454.45.