[php] escaped characters (unicode in pdflib)

[riotrick]

Om unicode characters met pdflib te kunnen schrijven moet ik een escaped karakter aan een functie meegeven:

pdf_show_xy($pdf,"\x94") ,$xpos,$ypos);

Het gaat hierbij om de \x94. Op deze manier werkt het prima.

Echter wanneer ik nu uit een input veld 94 heb geparsed wil ik daar \x94 van maken. Dit krijg ik echt niet voor elkaar.

$var = 94
pdf_show_xy($pdf,"\x".$var) ,$xpos,$ypos);

werkt niet. single quoten, double quoten, escapen van de \x. strval() om het gebeuren zetten, string maken met een sprintf(). Het heeft allemaal geen effect


Volgens mij heb ik te maken met iets wat precies in de pdflib manual beschreven staat voor de c++ binding van pdflib:

Unicode in the C++ language binding. C++ users must be aware of a pitfall related to the compiler automatically converting literal strings to the C++ string type which is expected by the PDFlib API functions: this conversion supports embedded null characters only if an explicit length parameter is supplied. For example, the following will not work since the string will be truncated at the first null character:

p.show("\x00\x41\x96\x7B\x8C\xEA"); // Wrong!

To fix this problem apply the string constructor with an explicit length parameter:

p.show(string("\x00\x41\x96\x7B\x8C\xEA", 6)); // Correct


Goed leuk en aardig, maar een equivalent voor de c++ string() functie is er voor zover ik weet niet in php.

Heeft iemand enig idee hoe dit op te lossen is?

Mijn dank zou best wel redelijk zijn

[riotrick]

Problem is solved inmiddels
Wil je \x94 maken bijvoorbeeld dan kan dat simpel met chr(hexdec(94));

[Janoz]

Waar het in je startpost mis ging is dat die \x94 al in een speciaal teken wordt omgezet zodra je programma wordt geparsed. Vergelijk het met een newline. Waneer je \n in een string zet in je programma wordt in het geheugen niet exact \n opgeslagen, maar een newline teken. Wil je daadwerkelijk een \ en daarachter een n in je string hebben dan zul je \\n moeten gebruiken.

In je voorbeeld word \x in de string gezet. De parser kan hier niks speciaals van maken en interpreteerd dit maar gewoon als een x. Later plak je er een nummer achter en wordt het x95 wat je waarschijnlijk op je pdf pagina te zien kreeg. Wat je quote mbt de C lib komt wel redelijk overeen, maar niet helemaal aangezien het hier specifiek over een nul byte gaat die binnen c over het algemeen wordt gebruikt om het einde van een string aan te geven.