---

Pga. omstændighederne er jeg tvunget til at bruge M$ Word 2004 sat op
til at arbejde i Unicode. Til min skræk og rædsel ser jeg, at man kun
kan vælge Unicode UTF-16 og ikke UTF-7 og/eller UTF-8. - Det vil
uvilkårlig give problemer, da jeg skal bruge den til nogle test og
tekstsammenligninger med NisusWriter Express og multi-language
dokumenter - engelsk, arabisk, persisk, hebraisk + japansk i samme dokument.

Er der nogen mulighed for at tvangssætte den til UTF-7 eller UTF-8?

mvh. Erik Richard
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:

> til at arbejde i Unicode. Til min skræk og rædsel ser jeg, at man kun
> kan vælge Unicode UTF-16 og ikke UTF-7 og/eller UTF-8. - Det vil

Unicode er 16-bit.

UTF-16, UTF-7 og UTF-8 er forskellige komprimeringsalgoritmer til at
folde 16-bitværdierne ned i 8-bits bytes, sædvanligvis for at spare
plads eller være kompatibelt med et eller andet (eks US-ASCII).

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Hej Thorbjørn

Thorbjørn Ravn Andersen wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:
>> til at arbejde i Unicode. Til min skræk og rædsel ser jeg, at man kun
>> kan vælge Unicode UTF-16 og ikke UTF-7 og/eller UTF-8. - Det vil
>
> Unicode er 16-bit.

Det véd jeg godt...

> UTF-16, UTF-7 og UTF-8 er forskellige komprimeringsalgoritmer til at
> folde 16-bitværdierne ned i 8-bits bytes, sædvanligvis for at spare
> plads eller være kompatibelt med et eller andet (eks US-ASCII).

Problemet er jo bare, at ikke alle skrifttyper vil lade sig genkende,
hvis man bruger UTF-16. - Nogle af de mest brugte skrifter i fx. japansk
er de såkaldte 'Hiragana' og 'Katagana', - begge er rene UTF-8
skrifter... - Det går så lidt lettere med de semittiske skrifter...

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:

> Problemet er jo bare, at ikke alle skrifttyper vil lade sig
> genkende, hvis man bruger UTF-16. - Nogle af de mest brugte skrifter
> i fx. japansk er de såkaldte 'Hiragana' og 'Katagana', - begge er
> rene UTF-8 skrifter... - Det går så lidt lettere med de semittiske
> skrifter...

Ovenstående fatter jeg ganske enkelt ikke en bjælde af.

Kan du prøve at forklare det lidt tydeligere?
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Hej Thorbjørn

Thorbjørn Ravn Andersen wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:
>> Problemet er jo bare, at ikke alle skrifttyper vil lade sig
>> genkende, hvis man bruger UTF-16. - Nogle af de mest brugte skrifter
>> i fx. japansk er de såkaldte 'Hiragana' og 'Katagana', - begge er
>> rene UTF-8 skrifter... - Det går så lidt lettere med de semittiske
>> skrifter...
>
> Ovenstående fatter jeg ganske enkelt ikke en bjælde af.

Det gør jeg heller ikke. - Men jeg kan godt se, når to tegn er ens,
og/eller om de hører sammen...

> Kan du prøve at forklare det lidt tydeligere?

BÃ¥de Hiragana og Katagana er UFT-7/8 skrifttyper, der findes identiske
til Windows/Mac og kan bruges sammen med MSOffice 2003 for Windows'
'Asian Language Input' modul. Hvis man så åbner et sådant dokument, der
er gemt som RTF i fx. NisusWriter Express, vil den vise skrifterne
korrekt. - NWE er UTF-8 savvy. NWE bruger UTF-8 som standard - men har
ikke UFT-16 compatibility i font substitution.

Hvis du bruger MSOffice 2004 til Mac og laver samme dokument, kan du
godt bruge både Hiragana og Katagana skrifterne, og de vil også vises
korrekt i MSO til Windows og Mac, hvis skrifterne er installeret på
begge platforme. - MEN - hvis du gemmer som RTF og åbner i NWE, vil NWEs
'font substitution' nogle gange vælge 'NISC18030' eller '儷宋 Pro'
(hører til Nihon-gruppen) eller sågar den kinesiske 'FongSong' eller
'Song' skrift, der begge er både UTF-8 og UTF-16 savvy.

Hvis man derimod bruger MS ArialUnicode.ttf (100% glyph-baseret UFT-8/16
skrift) til komposition af et multi-lingual dokument på Windows og
gemmer i RTF, og man ikke har ArialUnicode på sin Mac, går det helt
galt. - Det kan hverken NWE eller MSWD2004 finde ud af... Når man åbner
et sådant dokument, vil der blot være tegn og underlige gerninger...

Jeg véd godt, man kunne implementere UTF-16 kompatibilitet i fx. NWE,
men alene den del vil fylde omk. 8-10mb, - dels i form af direkte
programimplementering, dels i konvertere, og da NWE _ikke_ betjener sig
af eksterne konvertere, skal det hele implementeres i selve programmet.
- Da NWE i forvejen fylder ca. 25mb, vil det betyde, at selve programmet
vil komme op og fylde ca. 34-35mb i sig selv, - og det med en væsentlig
hastighedsnedsættelse til følge....

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Hej Thorbjørn

Thorbjørn Ravn Andersen wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:
>> Problemet er jo bare, at ikke alle skrifttyper vil lade sig
>> genkende, hvis man bruger UTF-16. - Nogle af de mest brugte skrifter
>> i fx. japansk er de såkaldte 'Hiragana' og 'Katagana', - begge er
>> rene UTF-8 skrifter... - Det går så lidt lettere med de semittiske
>> skrifter...
>
> Ovenstående fatter jeg ganske enkelt ikke en bjælde af.

Det gør jeg heller ikke. - Men jeg kan godt se, når to tegn er ens,
og/eller om de hører sammen...

> Kan du prøve at forklare det lidt tydeligere?

BÃ¥de Hiragana og Katagana er UFT-7/8 skrifttyper, der findes identiske
til Windows/Mac og kan bruges sammen med MSOffice 2003 for Windows'
'Asian Language Input' modul. Hvis man så åbner et sådant dokument, der
er gemt som RTF i fx. NisusWriter Express, vil den vise skrifterne
korrekt. - NWE er UTF-8 savvy. NWE bruger UTF-8 som standard - men har
ikke UFT-16 compatibility i font substitution.

Hvis du bruger MSOffice 2004 til Mac og laver samme dokument, kan du
godt bruge både Hiragana og Katagana skrifterne, og de vil ogsåvises
korrekt i MSO til Windows og Mac, hvis skrifterne er installeret på
begge platforme. - MEN - hvis du gemmer som RTF og åbner i NWE, vil NWEs
'font substitution' nogle gange vælge 'NISC18030' eller '儷宋 Pro'
(hører til Nihon-gruppen) eller sågar den kinesiske 'FongSong' eller
'Song' skrift, der begge er både UTF-8 og UTF-16 savvy.

Hvis man derimod bruger MS ArialUnicode.ttf (100% glyph-baseret UFT-8/16
skrift) til komposition af et multi-lingual dokument på Windows og
gemmer i RTF, og man ikke har ArialUnicode på sin Mac, går det helt
galt. - Det kan hverken NWE eller MSWD2004 finde ud af... Når man åbner
et sådant dokument, vil der blot være tegn og underlige gerninger...

Jeg véd godt, man kunne implementere UTF-16 kompatibilitet i fx. NWE,
men alene den del vil fylde omk. 8-10mb, - dels i form af direkte
programimplementering, dels i konvertere, og da NWE _ikke_ betjener sig
af eksterne konvertere, skal det hele implementeres i selve programmet.
- Da NWE i forvejen fylder ca. 25mb, vil det betyde, at selve programmet
vil komme op og fylde ca. 34-35mb i sig selv, - og det med en væsentlig
hastighedsnedsættelse til følge....

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:

> begge platforme. - MEN - hvis du gemmer som RTF og åbner i NWE, vil
> NWEs 'font substitution' nogle gange vælge 'NISC18030' eller

SOm jeg forstår det, indeholder RTF ikke selve fontene, hvorfor
fontsubstituering skal ske.

At jeg ikke forstår det konkrete problem du har, må skyldes
forskellighed i koden i de to programmers fontsubstitution, og jeg
tror ikke det skyldes det du tror.

> Jeg véd godt, man kunne implementere UTF-16 kompatibilitet i fx. NWE,
> men alene den del vil fylde omk. 8-10mb, - dels i form af direkte
> programimplementering, dels i konvertere, og da NWE _ikke_ betjener

Det begriber jeg heller ikke. Bruger man Unicode bruger man 16-bit
tegn, punktum finale.

UTF-8, UTF-7 og UTF-16 er bare forskellige algoritmer til at dekode
disse 16-bit tegn, og hver algoritme kan uden problemer stå på et
A4-ark.

Jeg tror vitterligt at det du ser, ikke skyldes det du tror.

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Hej Thorbjørn

Thorbjørn Ravn Andersen wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:
>> begge platforme. - MEN - hvis du gemmer som RTF og åbner i NWE, vil
>> NWEs 'font substitution' nogle gange vælge 'NISC18030' eller
>
> SOm jeg forstår det, indeholder RTF ikke selve fontene, hvorfor
> fontsubstituering skal ske.

Korrekt. - 'Font Embedding' er fjernet fra MSOffice X/2004. - Det var
ellers en af de få rimeligt brugbare funktioner, når man valgte RTF som
arkivformat. NWE har aldrig haft FE implementeret...

> At jeg ikke forstår det konkrete problem du har, må skyldes
> forskellighed i koden i de to programmers fontsubstitution, og jeg
> tror ikke det skyldes det du tror.

Vi har arbejdet på problemet de sidste godt 2 år nu, og det er da også
blevet en smule bedre, da M$ frigav RTF koden til Office X (ikke til
MSO2004), men der er stadig meget store problemer med visse af M$'s
Unicode skrifter og deres nye UTF-16 standard.

Vi kan faktisk bevise, at problemet ligger i UTF-16 og ikke i fx. RTF,
hvad man burde tro.... - Og hvorfor er der så ingen problemer, når der
bruges UTF-7/8? - Og hvorfor er MSO/Word det eneste program, der er
unicode savvy, hvor man ikke selv kan vælge mellem UTF-7/8 og UTF-16?

I Nisus Software har vi valgt at koncentrere os om UTF-8 som
'recommended arkivformat, da det jo er det mest udbredte format - alle
programmer set under ét. Desuden er der en unicode format mere, der er
bedst ved brug af kinesisk, men det format kan ikke anbefales i
multi-lingual tekster...

>> Jeg véd godt, man kunne implementere UTF-16 kompatibilitet i fx. NWE,
>> men alene den del vil fylde omk. 8-10mb, - dels i form af direkte
>> programimplementering, dels i konvertere, og da NWE _ikke_ betjener
>
> Det begriber jeg heller ikke. Bruger man Unicode bruger man 16-bit
> tegn, punktum finale.
>
> UTF-8, UTF-7 og UTF-16 er bare forskellige algoritmer til at dekode
> disse 16-bit tegn, og hver algoritme kan uden problemer stå på et
> A4-ark.
>
> Jeg tror vitterligt at det du ser, ikke skyldes det du tror.

- Så forklar mig lige, hvorfor, der ikke opstår samme fejl, hvis
dokumenter er lavet med UTF-8 i fx. MarinerWrite, NeoOffice, Abiword
eller Mellel til Mac og Abiword, OpenOffice, WordPerfect og StarWrite
til Windows??? - og hvor der er gemt i RTF og åbnet i NisusWriter
Express.... - Problemet er der heller ikke, hvis man gemmer og åbner
indbyrdes mellem disse programmer - kun når M$Word er blandet ind i det,
går det galt...

- Jeg véd, jeg er rimelig skrap, når det gælder skrifter og
skriftstyring, men her står jeg af.!

Undskyld mig, - men det er som om M$ hver gang, man er ved at få has på
Unocode+RTF, vælger nyt format. - Først var det skiftet fra UTF-7 til
UTF-8, - og nu har de så skiftet til UTF-16, - og alle problemer vendet
tilbage. !!

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:

> Vi kan faktisk bevise, at problemet ligger i UTF-16 og ikke i fx. RTF,

Erik, nu har du forvirret mig igen. UTF-16 er en indkodningsform, og
RTF er et dokumentformat.

> - Så forklar mig lige, hvorfor, der ikke opstår samme fejl, hvis
> dokumenter er lavet med UTF-8 i fx. MarinerWrite, NeoOffice, Abiword
> eller Mellel til Mac og Abiword, OpenOffice, WordPerfect og StarWrite
> til Windows??? - og hvor der er gemt i RTF og åbnet i NisusWriter

Det kan jeg da ikke. Fordi Microsoft gør ting anderledes?

Jeg tror nu stadigvæk du blander begreber sammen.
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Hej Thorbjørn

Thorbjørn Ravn Andersen wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:
>> Vi kan faktisk bevise, at problemet ligger i UTF-16 og ikke i fx. RTF,
>
> Erik, nu har du forvirret mig igen. UTF-16 er en indkodningsform, og
> RTF er et dokumentformat.

- Så véd jeg snart ikke, hvordan jeg skal skrive det...

Men jeg prøver igen... Bruger du MSWord Mac/Win med UTF-16, gemmer i RTF
og åbner med andre programmer, der _IKKE_ understøtter UTF-16, går det galt.

Bruger du en ældre Word Mac/Win, der kun har UTF-7/8, gemmer i RTF og
åbner - igen - med de programmer, jeg har nævnt, er der _INGEN_ problemer!

>> - Så forklar mig lige, hvorfor, der ikke opstår samme fejl, hvis
>> dokumenter er lavet med UTF-8 i fx. MarinerWrite, NeoOffice, Abiword
>> eller Mellel til Mac og Abiword, OpenOffice, WordPerfect og StarWrite
>> til Windows??? - og hvor der er gemt i RTF og åbnet i NisusWriter
>
> Det kan jeg da ikke. Fordi Microsoft gør ting anderledes?
>
> Jeg tror nu stadigvæk du blander begreber sammen.

Nej, jeg blander ikke noget sammen! - Problemet må nødvendigvis være med
UTF-16+RTF, når der ikke er samme problem med UTF-7/8+RTF. - Men hvor?

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:

> Nej, jeg blander ikke noget sammen! - Problemet må nødvendigvis være
> med UTF-16+RTF, når der ikke er samme problem med UTF-7/8+RTF. - Men
> hvor?

Kunne være Microsoft havde skrevet RTF-koden om...

Det er set før.

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:
> Erik Richard Sørensen <NOSPAM@NOSPAM.dk> writes:
>
>> Nej, jeg blander ikke noget sammen! - Problemet må nødvendigvis være
>> med UTF-16+RTF, når der ikke er samme problem med UTF-7/8+RTF. - Men
>> hvor?
>
> Kunne være Microsoft havde skrevet RTF-koden om...

Tja, det er måske 'løsningen'...

> Det er set før.

Hm, det blev den jo også fra Word 6/95/97 og til 98/2000, men det var
andre problemer, der kom dengang - tab af formatteret tekst i RTF ved
åbning i andre programmer...

mvh. ERik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Thorbjørn Ravn Andersen skrev:

> Unicode er 16-bit.

Unicode er vel blot en standard for numre for forskellige tegn. Og ikke
alle kan repræsenteres med 16 bit, selv om mest brugte kan:

"The majority of common-use characters fit into the first 64K code
points"
http://www.unicode.org/standard/principles.html

Og om UTF-16 på samme side:
"UTF-16 is popular in many environments that need to balance efficient
access to characters with economical use of storage. It is reasonably
compact and all the heavily used characters fit into a single 16-bit
code unit, while all other characters are accessible via pairs of 16-bit
code units."

> UTF-16, UTF-7 og UTF-8 er forskellige komprimeringsalgoritmer

Nemlig. Præcis som UTF-32. Og (igen fra samme side) om UTF-8, UTF-16 og
UTF-32:
"All three encoding forms need at most 4 bytes (or 32-bits) of data for
each character."

Hvis man skulle sige, at Unicode "er" noget, så må det altså være 32
bit...

--
Jesper Juellund Jensen

---

jjj@cyrk.dk (Jesper Juellund Jensen) writes:

> > Unicode er 16-bit.
>
> Unicode er vel blot en standard for numre for forskellige tegn. Og ikke
> alle kan repræsenteres med 16 bit, selv om mest brugte kan:

De unicode standarder jeg har kigget på har kun været 16-bit. Jeg har
vist godt hørt at det er blevet udvidet, men det har jeg ikke sat mig
ind i.

Desuden har det mest været javaimplementationer hvor tegn er 16-bit.

> Hvis man skulle sige, at Unicode "er" noget, så må det altså være 32
> bit...

32 bits tegn, for at være helt præcis.

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:
> jjj@cyrk.dk (Jesper Juellund Jensen) writes:
>
>>> Unicode er 16-bit.
>> Unicode er vel blot en standard for numre for forskellige tegn. Og ikke
>> alle kan repræsenteres med 16 bit, selv om mest brugte kan:
>
> De unicode standarder jeg har kigget på har kun været 16-bit. Jeg har
> vist godt hørt at det er blevet udvidet, men det har jeg ikke sat mig
> ind i.
>
> Desuden har det mest været javaimplementationer hvor tegn er 16-bit.
>
Nej. Sun Java API'et String klasse bruger intern UTF-16. Som Jesper så
fint forklarede er der forskel på om man taler om indkodningen af
unicode tegn, eller tegnenes kode punkter i unicode standarden.
Unicode inddeler tegn i 17 planes. Hvor hvert plane kan indehold op til
2^16 tegn. Altså 1114112 tegn.
Men det er fuldstændig forkert at tale om at unicode 'er' noget i bit's.
Man kan tale om hvormange bits en given indkodning bruger. Men unicode i
sig selv siger intet om hvordan tegnene skal repræsenteres på en binær
maskine.

Venlig hilsen
Mads

---

Mads <mads@iname.com> writes:

> > Desuden har det mest været javaimplementationer hvor tegn er 16-bit.
> >
> Nej. Sun Java API'et String klasse bruger intern UTF-16. Som Jesper så

En char i Java er 16 bit.

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Thorbjørn Ravn Andersen wrote:
> Mads <mads@iname.com> writes:
>
>>> Desuden har det mest været javaimplementationer hvor tegn er 16-bit.
>>>
>> Nej. Sun Java API'et String klasse bruger intern UTF-16. Som Jesper så
>
> En char i Java er 16 bit.
>
Ja, og? Hvis man læser Java 1.5 doc'en så fremgår det at Java benytter
sig af 2 chars til alt andet end unicode plane 0.
At char er 16-bit skal nok ses som en historisk konsekevens af at da
Sun's Oak projekt i 1992 eller deromkring definerede Java sproget så
fandtes kun unicode plane 0 (og den blev bare kaldt unicode).

Venlig hilsen
Mads

---

Hej Jesper

Jesper Juellund Jensen wrote:
> Thorbjørn Ravn Andersen skrev:
>> Unicode er 16-bit.
>
> Unicode er vel blot en standard for numre for forskellige tegn. Og ikke
> alle kan repræsenteres med 16 bit, selv om mest brugte kan:
>
> "The majority of common-use characters fit into the first 64K code
> points"
> http://www.unicode.org/standard/principles.html
>
> Og om UTF-16 på samme side:
> "UTF-16 is popular in many environments that need to balance efficient
> access to characters with economical use of storage. It is reasonably
> compact and all the heavily used characters fit into a single 16-bit
> code unit, while all other characters are accessible via pairs of 16-bit
> code units."
>
>> UTF-16, UTF-7 og UTF-8 er forskellige komprimeringsalgoritmer
>
> Nemlig. Præcis som UTF-32. Og (igen fra samme side) om UTF-8, UTF-16 og
> UTF-32:
> "All three encoding forms need at most 4 bytes (or 32-bits) of data for
> each character."

Bingo! - Dér gav du løsningen, - nok uden du selv er klar over det.

> Hvis man skulle sige, at Unicode "er" noget, så må det altså være 32
> bit...

Det var '32', der ledte mig på sporet. De asiatiske billedtegnssprog -
japansk, kinesisk og koreansk er 2-bytes sprog - altså 16 bits, hvis man
tænker i alm. konventionelle skrifttyper ala PS, T1 og TT, men for at
have plads til alle tegn i _1_ enkelt skrifttype, arbejder mange
programmer og filformater ud fra en 'double 2-bytes' kodning - altså
reelt en 4-bytes kodning... Det kan RTF _ikke_ finde ud af, og det
betyder, at hvis glyph'erne i skrifttegnet ikke er fuldstændig nøjagtig
lig med samme tegn i en 2-bytes skrifttegn, vil M$ font substitution
vælge en kodning, der ligger i nærheden af tegnets glyph.

Men det betyder så også, at der ikke er en løsning, før alle skrifttegn
er både 16-bits og 32-bits savvy, og at dette bliver implementeret i RTF
koden.

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen wrote:
>
> Det var '32', der ledte mig på sporet. De asiatiske billedtegnssprog -
> japansk, kinesisk og koreansk er 2-bytes sprog - altså 16 bits

Det giver ikke mening. Det er korrekt at med visse kodnings standarder
for unicode bruger 16-bit til de fleste kinesiske tegn. Men "2-bytes
sprog" giver ikke mening.

> , hvis man
> tænker i alm. konventionelle skrifttyper ala PS, T1 og TT, men for at
> have plads til alle tegn i _1_ enkelt skrifttype, arbejder mange
> programmer og filformater ud fra en 'double 2-bytes' kodning - altså
> reelt en 4-bytes kodning...

Det jeg tror du forsøger at sige er at omkring år 2000 begyndte Kina at
kræve support for tegn der lå udover unicode BMP'en. Derfor måtte man
enten bruge en større fast længde kodning såsom UCS-4 (32 bit), eller en
variable længde kodning som f.eks. UTF-16 (der som minimum bruger 16
bit, og i nogle tilfælde mere)

>
> Men det betyder så også, at der ikke er en løsning, før alle skrifttegn
> er både 16-bits og 32-bits savvy, og at dette bliver implementeret i RTF
> koden.
>
Skriftyper burde ikke have noget at gøre med kodningen. De burde
beskæftige sig på en stream a unicode kode punkter, hvis det er en
unicode skriftype.
Normalt vil det dog være gemt væk i OS'ets 2D rendering. Jeg kender ikke
MS's Uniscribe så godt, men Apples Type Services for Unicode tager
såvidt jeg husker UTF-16 kodning fra applikationer og mapper dette til
den ønskede font.
Denne mapning er ikke nødvendigvis triviel, da den kan tage en del
forskellige parametre med i dens beregninger.

Venlig hilsen
Mads

---

Mads <mads@iname.com> writes:

> Det giver ikke mening. Det er korrekt at med visse kodnings standarder
> for unicode bruger 16-bit til de fleste kinesiske tegn. Men "2-bytes
> sprog" giver ikke mening.

Der er mange DoubleByte-tegnsæt fra før Unicodes tid.

Unicode er generelt en god ting.
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"

---

Hej Mads

Mads wrote:
> Erik Richard Sørensen wrote:
>> Det var '32', der ledte mig på sporet. De asiatiske billedtegnssprog -
>> japansk, kinesisk og koreansk er 2-bytes sprog - altså 16 bits
>
> Det giver ikke mening. Det er korrekt at med visse kodnings standarder
> for unicode bruger 16-bit til de fleste kinesiske tegn. Men "2-bytes
> sprog" giver ikke mening.

Joda. Kinesisk, japansk og koreansk _er_ 2-bytes sprog jvf. Apple
WorldScript II, så det giver endda rigtig god mening.

I princippet deler Apple helt tilbage fra System 6.0.5 sprog op i 1-byte
- 'WorldScript I' - alle latinske, cyrilliske og semittiske alfabeter,
og 2-bytes - 'WorldScript II' alle billedtegnssprog.

>> , hvis man
>> tænker i alm. konventionelle skrifttyper ala PS, T1 og TT, men for at
>> have plads til alle tegn i _1_ enkelt skrifttype, arbejder mange
>> programmer og filformater ud fra en 'double 2-bytes' kodning - altså
>> reelt en 4-bytes kodning...
>
> Det jeg tror du forsøger at sige er at omkring år 2000 begyndte Kina at
> kræve support for tegn der lå udover unicode BMP'en. Derfor måtte man
> enten bruge en større fast længde kodning såsom UCS-4 (32 bit), eller en
> variable længde kodning som f.eks. UTF-16 (der som minimum bruger 16
> bit, og i nogle tilfælde mere)

Det gjorde de også, men det er ikke lige det. - Jeg kan godt se, det er
lidt 'kluntet' formuleret, og jeg burde nok have skrevet forskelligheden
mellem UTF-8/WorldScript II og UTF-16 og dens måde at _håpndtere_
WorldScript II på.

I de nye billedtegnsskrifter i UTF-8 (WS II) har du alle tegn i
'Simplified Chinese', - svjh. godt og vel 7.000 skrifttegn og i
'Traditional Chinese (Mandarin Chinese) har du ca. 23.000 skrifttegn ud
af de i alt ca. 70.000 tegn i Mandarin, samt ca. 1200 såkaltde
'technical characters' - tegn, som nødvendigvis er indkorporeret i
sproget til brug ved fx. konstruktion, fremmede måleenheder osv.osv..

>> Men det betyder så også, at der ikke er en løsning, før alle
>> skrifttegn er både 16-bits og 32-bits savvy, og at dette bliver
>> implementeret i RTF koden.
>
> Skriftyper burde ikke have noget at gøre med kodningen. De burde
> beskæftige sig på en stream a unicode kode punkter, hvis det er en
> unicode skriftype.
> Normalt vil det dog være gemt væk i OS'ets 2D rendering. Jeg kender ikke
> MS's Uniscribe så godt, men Apples Type Services for Unicode tager
> såvidt jeg husker UTF-16 kodning fra applikationer og mapper dette til
> den ønskede font.

Det er ikke alle de billedtegnsskrifter, der er i Mac OS X, der er
Unicode, og dem, der er, er kun UTF-8 - ikke UTF-16 - fx. SongFong
(Trad.Chin.), Fong (Simp.Chin.), NISC (Nihon, jap.), TaiPe (Simp.Chin.
Taiwan), UnSon (Kwan, kor.) osv.osv.. Disse er alle .dfont
transcriptioner af tilsv. WS II skrifttyper.

> Denne mapning er ikke nødvendigvis triviel, da den kan tage en del
> forskellige parametre med i dens beregninger.

Tja, muligvis... Det burde bare være sådan, at alle skrifttyper var
fuldt ud kompatible med og i alle programmer, hvor man kan vælge anden
skrifttype. - Ét er bare _helt_ sikker. - Det giver problemer, når
dokumenter gemmes i RTF, dog lidt færre problemer i de programmer, der
har både den gamle std. RTF + MS RTF som fx. MarinerWrite...

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Hej Erik

Erik Richard Sørensen wrote:
> Mads wrote:
>
> Joda. Kinesisk, japansk og koreansk _er_ 2-bytes sprog jvf. Apple
> WorldScript II, så det giver endda rigtig god mening.
>
Det er da ikke 2-bytes hvis jeg vil bruge UCS-4.
Jeg er udemærket klar over at visse kodnings standarder har kodet
kinesisk med 2 bytes. Jeg sad i Beijing og kodede kinesiske Delphi
programmer inden Delphi fik Unicode support, så jeg har været turen igennem.

> I princippet deler Apple helt tilbage fra System 6.0.5 sprog op i 1-byte
> - 'WorldScript I' - alle latinske, cyrilliske og semittiske alfabeter,
> og 2-bytes - 'WorldScript II' alle billedtegnssprog.
>
Undskyld, men er WorldScript ikke død og begravet sammen med OS 9?
Det kan være jeg husker fejl, men såvidt jeg husker kunne WorldScript
ikke håndtere unicode, det kunne derimod Apple Type Services for Unicode
Imaging.

>
> Det er ikke alle de billedtegnsskrifter, der er i Mac OS X, der er
> Unicode, og dem, der er, er kun UTF-8 - ikke UTF-16 - fx. SongFong
> (Trad.Chin.), Fong (Simp.Chin.), NISC (Nihon, jap.), TaiPe (Simp.Chin.
> Taiwan), UnSon (Kwan, kor.) osv.osv.. Disse er alle .dfont
> transcriptioner af tilsv. WS II skrifttyper.
>
Mærkeligt mine kinesiske fonte på min Intel Mac hedder noget helt andet.
Hvordan ser du på en font at den kun er UTF-8?

>> Denne mapning er ikke nødvendigvis triviel, da den kan tage en del
>> forskellige parametre med i dens beregninger.
>
> Tja, muligvis...
Er der ikke en hel stak regler i unicode standarden for hvordan på
hinanden følgende tegn skal tegnes. Samt styring af blandet
Right-to-left og Left-to-right sprog?

> Det burde bare være sådan, at alle skrifttyper var
> fuldt ud kompatible med og i alle programmer, hvor man kan vælge anden
> skrifttype.
Enig.

> - Ét er bare _helt_ sikker. - Det giver problemer, når
> dokumenter gemmes i RTF, dog lidt færre problemer i de programmer, der
> har både den gamle std. RTF + MS RTF som fx. MarinerWrite...
>
Ja, mærkeligt. Men som du selv er inde på skyldes det nok at RTF er et
gammelt format der har fået eftermonteret support for andet end ASCII tegn.

Venlig hilsen
Mads

---

Mads <mads@iname.com> wrote:

> > - Ét er bare _helt_ sikker. - Det giver problemer, når
> > dokumenter gemmes i RTF, dog lidt færre problemer i de programmer, der
> > har både den gamle std. RTF + MS RTF som fx. MarinerWrite...
> >
> Ja, mærkeligt. Men som du selv er inde på skyldes det nok at RTF er et
> gammelt format der har fået eftermonteret support for andet end ASCII tegn.

Hvilken generisk format burde man så bruge. Jeg har sværget til rtf i
det pædagogiske miljø, men oplever jævnligt fejl alligevel. Er derfor
blevet mere ydmyg med mine anbefalinger.
Ellers erfarer jeg for mit eget vedkommende at jeg bruger pdf mere og
mere.

--
Med venlig hilsen
Flemming Rubini

E-post: brug reply for at få korrekt adresse.

---

Hej Mads

Mads wrote:
> Erik Richard Sørensen wrote:
>> Mads wrote:
>> Joda. Kinesisk, japansk og koreansk _er_ 2-bytes sprog jvf. Apple
>> WorldScript II, så det giver endda rigtig god mening.
>
> Det er da ikke 2-bytes hvis jeg vil bruge UCS-4.

Mig bekendt kan man ikke bruge UCS-4 på OS X...

> Jeg er udemærket klar over at visse kodnings standarder har kodet
> kinesisk med 2 bytes. Jeg sad i Beijing og kodede kinesiske Delphi
> programmer inden Delphi fik Unicode support, så jeg har været turen
> igennem.

Det, jeg tænker på, er først og fremmest de lidt ældre skrifttyper, der
stadig bruges af mange Mac brugere. De er 2-bytes opbygning beregnet til
brug med WorldScript II.

>> I princippet deler Apple helt tilbage fra System 6.0.5 sprog op i
>> 1-byte - 'WorldScript I' - alle latinske, cyrilliske og semittiske
>> alfabeter, og 2-bytes - 'WorldScript II' alle billedtegnssprog.
>
> Undskyld, men er WorldScript ikke død og begravet sammen med OS 9?
> Det kan være jeg husker fejl, men såvidt jeg husker kunne WorldScript
> ikke håndtere unicode, det kunne derimod Apple Type Services for Unicode
> Imaging.

Som selvstændig skrifthåndtering, jo, så er WorldScript afgået ved en -
desværre - stille og rolig død. Men håndteringen er nu inkluderet i
TypeServices, netop for at kunne bibeholde brugen af mange af de
klassikse WorldScript II savvy skriftr - som fx. 'BeiJing, TaiPe,
Shanghai, LiSong osv.. Alle disse er rene 2-bytes skrifter...

>> Det er ikke alle de billedtegnsskrifter, der er i Mac OS X, der er
>> Unicode, og dem, der er, er kun UTF-8 - ikke UTF-16 - fx. SongFong
>> (Trad.Chin.), Fong (Simp.Chin.), NISC (Nihon, jap.), TaiPe (Simp.Chin.
>> Taiwan), UnSon (Kwan, kor.) osv.osv.. Disse er alle .dfont
>> transcriptioner af tilsv. WS II skrifttyper.
>
> Mærkeligt mine kinesiske fonte på min Intel Mac hedder noget helt andet.

Hm, hvor jeg har fået dem fra, tør jeg egentlig ikke sige, men det er de
skrifter, jeg har brugt i de sammenligninger og tests, jeg har været
igang med. Nogle af dem er TT konverteringer af Windows .ttf skrifter.

> Hvordan ser du på en font at den kun er UTF-8?

Det har jeg fra dem, jeg har fået dokumenterne fra.

>>> Denne mapning er ikke nødvendigvis triviel, da den kan tage en del
>>> forskellige parametre med i dens beregninger.
>>
>> Tja, muligvis...
> Er der ikke en hel stak regler i unicode standarden for hvordan på
> hinanden følgende tegn skal tegnes.

Det går jeg da stærkt ud fra, - ellers vil det da gå helt i ged.

> Samt styring af blandet Right-to-left og Left-to-right sprog?

det er det enkelte tekstbehandlingsprogram, der styrer det. - Fx. i både
NisusWriter Express, Mellel og MarinerWrite er det enten med et klik på
en knap eller via en tastkommando.

>> Det burde bare være sådan, at alle skrifttyper var
>> fuldt ud kompatible med og i alle programmer, hvor man kan vælge anden
>> skrifttype.
> Enig.
>
>> - Ét er bare _helt_ sikker. - Det giver problemer, når dokumenter
>> gemmes i RTF, dog lidt færre problemer i de programmer, der har både
>> den gamle std. RTF + MS RTF som fx. MarinerWrite...
>
> Ja, mærkeligt. Men som du selv er inde på skyldes det nok at RTF er et
> gammelt format der har fået eftermonteret support for andet end ASCIItegn.

Hm, tjaoe... Men iflg. Ms's egen side, så er deres RTF fra både Office
XP og Office 2004 "...totally re-written code...".

Jeg har på fornemmelsen, at det er én af grundene til, at fx.
MarinerWrite nu har to forskellige RTF - alm. 'gammeldaws' RTF og
MS-RTF. Bruger jeg MS-RTF i MW og åbner et multi-lingual dokument i NWE,
er der færre fejl, end hvis jeg bruger den alm. RTF. - Jeg véd fra en af
mine venner, at han har lidt samme problem, når de får breve fra hans
kones familie i Thailand, skrevet i WordXP (Thai ver.) og gemt som RTF,
og de så åbner i den danske WordXP. Der er andre Thai skrifter i den
danske WinXP end i den lokaliserede thailandske version. Mine venner må
desuden bruge 'Asian Language Input', når de skriver breve på thai til
hendes familie. - Jeg har sagt, at han kun skal gemme i alm. .doc og det
vil den thailandske ver. af Word sagtens kunne håndtere, og det er da
også blevet bedre med kanp så mange fejlvisninger. - Jeg har spurgt ham,
om han har prøvet med Unicode i Office, men han er ikke så skrap til det
program-interne, så de vælger at bruge den alm. input metode...

Så med det, man 'samler op' rundt omkring, er jeg ved at være temmelig
sikker på, at fejlene ligger i RTF formatet. - Så jeg må da indrømme, at
jeg glæder mig lidt til, at .odf bliver std. på alle TB programmer, nu
hvor det er blevet ISO standard... - Jeg har prøvet en lille smule
sammenligning i Abiword og NeoOffice - Ingen fejl overhovedet - uanset
hvilken encoding, der er valgt!

mvh. Erik Richard

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

Erik Richard Sørensen wrote:
> Ét er bare _helt_ sikker. - Det giver problemer, når
> dokumenter gemmes i RTF, dog lidt færre problemer i de programmer, der
> har både den gamle std. RTF + MS RTF som fx. MarinerWrite...
>
Jeg kom til at tænke på. RTF er da et tekst baseret format, (i
modsætning til binære formater).
Så kan du ikke lave en simple fil med nogle enkelte tegn, og så åbne den
i en tekst editor og se hvad der går galt?

Jeg prøvede at skrive beijing på kinesisk i word og gemme dette og åbne
det i Emacs. Mod slutningen af filen fandt jeg:
\u21271\'b1\'b1\u20140
Hvor 21271 er decimal koden for Bei. Mens 20140 er decimal koden for
Jing. (Undskyld mit pinyin, jeg er idiot til tonefaldene)

Venlig hilsen
Mads

---

Hej Mads

god idé. Det prøver jeg ved lejlighed.
mvh. Erik Richard

Mads wrote:
> Erik Richard Sørensen wrote:
>> Ét er bare _helt_ sikker. - Det giver problemer, når dokumenter gemmes
>> i RTF, dog lidt færre problemer i de programmer, der har både den
>> gamle std. RTF + MS RTF som fx. MarinerWrite...
>>
> Jeg kom til at tænke på. RTF er da et tekst baseret format, (i
> modsætning til binære formater).
> Så kan du ikke lave en simple fil med nogle enkelte tegn, og så åbne den
> i en tekst editor og se hvad der går galt?
>
> Jeg prøvede at skrive beijing på kinesisk i word og gemme dette og åbne
> det i Emacs. Mod slutningen af filen fandt jeg:
> \u21271\'b1\'b1\u20140
> Hvor 21271 er decimal koden for Bei. Mens 20140 er decimal koden for
> Jing. (Undskyld mit pinyin, jeg er idiot til tonefaldene)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
KMLDenmark by Erik Richard Sørensen, Member of ADC
<kmldenmark_NOSP@M_stofanet.dk>
*Music Recording, Editing & Publishing - Also Smaller Quantities
*Software - For Theological Education - And For Physically Impaired
*Nisus - The Future in Text & Mail Processing <http://www.nisus.com>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~