PurePDF Version 2.0

[DoubleDutch]

This might be the cause? The routine 'ipf_escape' appears to have a limit of character 511 for characters above ascii 128?

Code: Select all

Procedure.s ipf_Escape(String$) ;Add \ before (, ) And \.
  Protected Char.c,Result$
  
  Result$=""
  
  For i=1 To Len(String$)
    Char=Asc(Mid(String$,i,1))
    Select Char
      Case 8 ; BS
        Result$+"\b"
      Case 9 ; TAB
        Result$+"\t"
      Case 10 ; LF
        Result$+"\n"
      Case 12 ; FF
        Result$+"\f"
      Case 13 ; CR
        Result$+"\r"
      Case '\'
        Result$+"\\"
      Case '('
        Result$+"\("
      Case ')'
        Result$+"\)"
      Case 128 To 511
        ;Debug Str(i)+":"+StrU(Char,#PB_Word)
        Result$+"\"+ipf_Dec2Oct(Char)
      Default
        Result$+Chr(Char)
    EndSelect
  Next
  ProcedureReturn Result$
EndProcedure

The characters I'm trying to display are these Hebrew characters:

Code: Select all

Case	$05F4:found=34	; HEBREW PUNCTUATION GERSHAYIM 
Case	$05F3:found=39	; HEBREW PUNCTUATION GERESH 
Case	$05BE:found=45	; HEBREW PUNCTUATION MAQAF 
Case	$05C3:found=58	; HEBREW PUNCTUATION SOF PASUQ 
Case	$05E9:found=35	; HEBREW LETTER SHIN 
Case	$05E2:found=40	; HEBREW LETTER AYIN 
Case	$05D0:found=41	; HEBREW LETTER ALEF 
Case	$05D8:found=43	; HEBREW LETTER TET 
Case	$05D1:found=66	; HEBREW LETTER BET 
Case	$05E6:found=67	; HEBREW LETTER TSADI 
Case	$05D3:found=68	; HEBREW LETTER DALET
Case	$05D2:found=71	; HEBREW LETTER GIMEL
Case	$05D4:found=72	; HEBREW LETTER HE			
Case	$05DB:found=75	; HEBREW LETTER KAF
Case	$05DC:found=76	; HEBREW LETTER LAMED
Case	$05DE:found=77	; HEBREW LETTER MEM
Case	$05E0:found=78	; HEBREW LETTER NUN
Case	$05E4:found=80	; HEBREW LETTER PE
Case	$05E7:found=81	; HEBREW LETTER QOF
Case	$05E8:found=82	; HEBREW LETTER RESH
Case	$05E1:found=83	; HEBREW LETTER SAMEKH
Case	$05EA:found=84	; HEBREW LETTER TAV
Case	$05D5:found=87	; HEBREW LETTER VAV
Case	$05D7:found=88	; HEBREW LETTER HET
Case	$05D9:found=89	; HEBREW LETTER YOD
Case	$05D6:found=90	; HEBREW LETTER ZAYIN
Case	$05E5:found=99	; HEBREW LETTER FINAL TSADI
Case	$05DA:found=107	; HEBREW LETTER FINAL KAF
Case	$05DD:found=109	; HEBREW LETTER FINAL MEM
Case	$05DF:found=110	; HEBREW LETTER FINAL NUN
Case	$05E3:found=112	; HEBREW LETTER FINAL PE
	
Case	$05B7:found=65	; HEBREW POINT PATAH 
Case	$05B7:found=69	; HEBREW POINT SEGOL 
Case	$05B8:found=70	; HEBREW POINT QAMATS
Case	$05B4:found=73	; HEBREW POINT HIRIQ
Case	$05B9:found=79	; HEBREW POINT HOLAM
Case	$05BB:found=85	; HEBREW POINT QUBUTS
Case	$05B2:found=97	; HEBREW POINT HATAF PATAH 
Case	$05B1:found=101	; HEBREW POINT HATAF SEGOL
Case	$05B3:found=102	; HEBREW POINT HATAF QAMATS
Case	$05B0:found=176	; HEBREW POINT SHEVA
Case	$05B5:found=181	; HEBREW POINT TSERE
Case	$05C1:found=186	; HEBREW POINT SHIN DOT

[ABBKlaus]

@DoubleDutch this is a limitation, haven´t found a way to implement unicode.

BR Klaus

[DoubleDutch]

This person has extended fpdf to cope with unicode/utf8 : http://acko.net/node/56

I'll take a look if you don't have time, but you might be more familiar with the fpdf system?

[DoubleDutch]

Also a different extension here: http://www.fpdf.org/en/script/script92.php

[ABBKlaus]

Thanks DoubleDutch this looks promising. At least i know know how to use a unicode font, but how to extract the cidtogid values?

[DoubleDutch]

Don't know, but it should be somewhere in that source. I think it is basically a hack to remap the unicode characters - I think the pdf spec allows for remapping of characters because it was created without unicode in mind?

[DoubleDutch]

This seems to explain it better I think - it might be easier if you see this solution:
http://www.peterkrantz.com/2007/utf8-in-pdf-writer/

[DoubleDutch]

I looked at the pdf reference document (v1.3) - it's an open standard.

Section 3.8.1 deals with Text Strings:

Certain strings contain information that is intended to be human-readable, such
as text annotations, bookmark names, article names, document information, and
so forth. Such strings are referred to as text strings. Text strings are encoded in
either PDFDocEncoding or Unicode character encoding. PDFDocEncoding is a
superset of the ISO Latin 1 encoding and is documented in Appendix D. Unicode
is described in the document The Unicode Standard (see the Bibliography).
For text strings encoded in Unicode, the first two bytes must be 254 followed by
255, representing the Unicode byte order marker, U+FEFF. (This sequence con-
flicts with the PDFDocEncoding character sequence thorn ydieresis, which is unlikely to be a meaningful beginning of a word or phrase.) The remainder of the
string consists of Unicode character codes, according to the UTF-16 encoding
specified in the Unicode standard, version 2.0. Commonly used Unicode values
are represented as 2 bytes per character, with the high-order byte appearing first
in the string.
Anywhere in a Unicode text string, an escape sequence may appear to indicate the
language in which subsequent text is written; this is useful when the language
cannot be determined from the character codes used in the text itself. The escape
sequence consists of the following elements, in order:
1. The Unicode value U+001B (that is, the byte sequence 0 followed by 27)
2. A 2-character ISO 639 language code—for example, EN for English or JA for
Japanese
3. (Optional) A 2-character ISO 3166 country code—for example, US for the
United States or JP for Japan
4. The Unicode value U+001B
The complete list of codes defined by ISO 639 and ISO 3166 can be obtained
from the International Organization for Standardization (see the Bibliography).

It looks like you put $fe $ff at the beginning of the string then carry on outputting the unicode string in hilo order. The spec version of the document should be at least 1.3

[ABBKlaus]

thanks for that info DoubleDutch, i know that Section of the pdf reference already but had no luck understanding it.
Maybe if i have some time in the future i will try again and report it here

[DoubleDutch]

Maybe if you add a command to insert raw data then I can test easily on the prebuilt libs and let you know?

[DoubleDutch]

I've been trying to compile on PB 4.60 and have included the source to purepdf (in the examples dir), but it won't compile because this structure is missing:

MEM_DataStructure

Any ideas?

[DoubleDutch]

Ahh - it's in the residents include - why?

[ABBKlaus]

Its needed by the compression example

[DoubleDutch]

Is the source in the example folder up to date (?), if so I plan on modifying it to conditionally work as a normal include or as a library - I'll then post the code back for you.

The only problem I've seen (so far) is with the pdf_image procedure as this has mem and memsize at the beginning of some of the optional parameters, but because the pb parameters don't support overloading then I'd have to move them to the end? Overloading is a nice feature of tailbite!

[ABBKlaus]

If you mean this one http://www.purebasicpower.de/?download= ... B45X86.zip then yes.

I don´t see a problem creating two functions for ipf_image()
Please explain what you mean with overloading, i never heard that before

Code: Select all

pdf_Image(FileName$, X.f, Y.f, W.f=0, H.f=0, Link.w=0)
pdf_ImageMem(Name$,*Mem,MemSize, X.f, Y.f, W.f=0, H.f=0, Link.w=0)