In che modo le annotazioni Acrobat codificare aggiunti come post-it ai file PDF?

Question

Abbiamo lettura e la scrittura Sticky Notes / Annotazioni / Commenti ai file PDF tramite un controllo ActiveX nella nostra applicazione per un certo numero di anni. Abbiamo recentemente aggiornato a Delphi2009 con supporto Unicode. Di seguito sta causando problemi.

Quando chiamiamo

CAcroPDAnnot.GetContents

I risultati sembrano essere piuttosto strano e noi perdiamo il nostro Unicode Caratteri. Non è come il risparmio come una stringa ANSI che di solito provoca il ritorno ????? invece otteniamo una stringa come

, ES, “ú,É • -z ×, ð,Ð, ¢, ½,ç

Per una stringa di caratteri giapponesi.

Tuttavia, se li risparmio i commenti nel pdf a un file di dati tramite il menu in PDF stesso è scritto in un file come qualcosa di simile

0kL0Oeå0k~¨ª0'0r0D0_0 ‰

Quest'ultimo può essere esportazione e reimportati in un PDF Acrobat e sarà ricreare i caratteri Unicode corretti. Tuttavia, una volta che io chiamo CAcroPDAnnot.GetContents nel mio codice che sta ritornando come qualcos'altro.

1. è rotto CAcroPDAnnot.GetContents?
2. Esiste uno schema di codifica che dovrei essere a conoscenza?
3. Esiste un'alternativa potrei essere in grado di fare?

Grazie

Answer 1

  

, ES, “ú,É • -z ×, ð,Ð, ¢, ½,ç

Questa è la stringa:

に 行 く 日 に 風邪 を ひ い た ら

in CP-932 aka codifica Shift-JIS, una codifica terribile, ma purtroppo ancora-popolare in Giappone.

Al momento stai interpretandolo come CP-1252 (Windows Europa occidentale). Se il componente PDF-lettura non convertirà automaticamente per voi, avrete bisogno di trovare un modo per rilevare quello che codifica per il documento è in e convertirlo manualmente.

Non so cosa Delphi prevede la lettura di codifiche, ma vi ho ottenuto le codifiche per Shift-JIS installati in Windows, dal Pannello di Controllo -> Opzioni internazionali -> opzione "Installa i file delle lingue dell'Asia orientale"? Se no, che potrebbe spiegare il motivo per cui sarebbe stato non riesce a convertire automaticamente, forse.

Answer 2

Non sei esattamente dandoci un sacco di informazioni su cui lavorare.

Lo prendo stai parlando dei "Acrobat.CAcroPDAnnot" Metodo di classe getContents qui. Quale versione di Acrobat stai usando? Avete forse passati versioni (o eseguire un aggiornamento) attorno al momento di iniziare la programmazione con Delphi 2009?

Quindi: come hai fatto a un'istanza dell'oggetto? Se si utilizza un file _TLB.pas * generato dalla DLL, siete certi che ancora lo confronta? (Prova a ri-generare, se incerta).

Terzo: come stai chiamando il metodo? Che tipo di variabile stai assegnando il risultato?

Ciò che potrebbe anche aiutare, è se si potesse fornire un campione di un'annotazione (preferibilmente compresa caratteri non-ASCII); e per questo l'annotazione:

• cosa dovrebbe simile (e che lo fa apparire come lettore interno)
• cosa restituisce quando si utilizza una versione pre-2009 della Delphi *
• quello che ritorna quando si utilizza Delphi 2009 *

(* preferibilmente i codici HEX byte degli (ANSI / larghezza) stringhe; ma uscita dal ispettore Ctrl-F7 dovrebbe fare)

Poi forse qualcuno potrebbe fornire una risposta più significativa.

Answer 3

Ok, una delle principali differenze tra Delphi 2009 e le versioni precedenti è che il tipo di stringa predefinito è una stringa unicode. Ciò significa che se si utilizza lo stesso componente ActiveX come nelle versioni precedenti, si sta passando stringhe Unicode in stringhe ASCII e che non è solitamente una buona idea.

Ci sono un paio di soluzioni per questo problema:

• provare se è possibile aggiornare il componente ActiveX in modo che supporti le stringhe Unicode completo.
• Usa AnsiString e non stringa di comunicare con il componente ActiveX. In questo caso, è comunque possibile utilizzare la vecchia interfaccia, ma si sta ancora legata alle stesse limitazioni.
• Utilizzare un altro controllo che crea pdf. C'è molto da trovare, ma essere pronti a cambiare una grossa fetta del vostro software. (Alcuni controlli sono basato su XML e l'uso di codifica.)