ŁG> Bo polskich znaczków _należy_ używać (kwestia ortografii i generalnie
ŁG> - kultury języka). A unikodu _jeszcze_ nie należy używać, bo jest za
ŁG> słabo supportowany.
Ale kto Unikod będzie suportować, jeżeli nikt go nie będzie używał?
Je m'explique. Kiedyś, dawno, dawno temu, Juznet był całkowicie
siedmio- bitowy (tylko ASCII). Ale Głupi Ludzie chcieli pisać
rdzennymi kreseczkami, umlautami, ogonkami, bukwami, robaczkami, i
temu podobnymi ideografami.
Mądrzy Ludzie cierpliwie tłumaczyli, że się nie da, że NNTP jest
siedmiobitowy, i że tego się nie da zmienić[1]. Głupi Ludzie
odpowiadali że tak, że owszem, że rozumieją że są problemy techniczne,
po czym cichcem zaczęli pisać patche na programy od niusów, aby ogonki
im wysyłały. Informacje ośmiobitowe przesyłali! Mądrzy Ludzie
popadli w panikę, i tak coś tam wspaniale zmajstrowali, że okazało
się, że NNTP wcale taki siedmiobitowy nie jest.
Wiele, wiele lat później, grupa ludzi, owszem mądrych, ale nie
informatyków, doszła do wniosku że nie tylko trzeba móc pisać po
Polsku, nie tylko po Arabsku, ale i po Polsku i po Arabsku w tym samym
liście, że nie tylko ideografami, ale też hieroglifami. I
zdefiniowali Unikod. Tym razem, Mądrzy Ludzie już wiedzieli, że nie
ma co Głupim Ludziom tłumaczyć, i przygotowali całą infrastrukturę.
Nie tylko to -- żeby Głupi Ludzie nie musieli sami patchować, Mądrzy
Ludzie przystosowali i Netszkapę, i Misie, i Lynxa, i TeX-a, i
XTerm-a, i konsolę żeby w Unikodzie pisały[2].
Ale Głupi Ludzie nie chcą w Unikodzie pisać. Z czego można tylko
wywnioskować, że Głupie Ludzie jak już się nauczyli Polskiego, to po
Arabsku nie chcą.
ŁG> Praktycznie _każdy_ system operacyjny (no, może
ŁG> oprócz tych na VM/cośtam, bo z nimi styczności nie miałem) pozwala na
ŁG> używanie, ew. filtrowanie polskich znaczków.
Filtrowanie prostego Unikodu (dokładnie, ISO 10646 poziom 1) nie jest
specjalnie trudniej zrobić niż filtrowanie ISO 8859-2. Pełny Unikod
jest owszem trudniej zaimplementować, ale przecież nie o to nam
chodzi.
Pozdrawiam,
J.
[1] Niektórzy im uwierzyli -- ob. narodowe wersje ISO 646, które są
czysto siedmiobitowe i w większości przypadków całkowicie
nieużyteczne.
[2] A co z Emacsem? Może nie powinienem Wam o tym mówić, ale od dwóch
lat trwają na ten temat rokowania. Po każdej rundzie dochodzi się do
tego samego wniosku -- wszyscy, ze Stallmanem włącznie, uważają że
jest to świetny pomysł, ale wszyscy czekają aż się kto inny za to
weźmie. (Ja też.)
>
> Ale kto Unikod będzie suportować, jeżeli nikt go nie będzie używał?
Zle przedmowce zrozumiales. Unikodu _mozna_ uzywac do pisania po polsku
(wylacznie), tylko po co? To jak strzelanie z armaty do wrobla. W kazdym
badz razie w grupach pl.* standard UTF-8 jest uznany za zlo wcielone.
> Ale Głupi Ludzie nie chcą w Unikodzie pisać. Z czego można tylko
Ja bardzo chetnie napisze cos w Unikodzie. Jesli sytuacja bedzie tego
wymagac (przewaznie nie wymaga). No i oczywiscie kwestia fontow, ale
to juz inna sprawa.
> wywnioskować, że Głupie Ludzie jak już się nauczyli Polskiego, to po
> Arabsku nie chcą.
Nie rozumiem. Obawiam sie jednak ze nikt w pl.* nie pisuje po arabsku.
> [1] Niektórzy im uwierzyli -- ob. narodowe wersje ISO 646, które są
> czysto siedmiobitowe i w większości przypadków całkowicie
> nieużyteczne.
Oraz zmuszaja do uzywania <shudder>trojgrafow</shudder> w C.
> [2] A co z Emacsem? Może nie powinienem Wam o tym mówić, ale od dwóch
> lat trwają na ten temat rokowania. Po każdej rundzie dochodzi się do
> tego samego wniosku -- wszyscy, ze Stallmanem włącznie, uważają że
> jest to świetny pomysł, ale wszyscy czekają aż się kto inny za to
> weźmie. (Ja też.)
To sie chyba impas nazywa?
GSN
> Ludzie przystosowali i Netszkapę, i Misie, i Lynxa, i TeX-a, i
> XTerm-a, i konsolę żeby w Unikodzie pisały[2].
Od kiedy TeX (ale ten prawdziwy a nie Omega) jest unikodowy ?
Alex
--
Janusz A. "Alex" Urbanowicz, student of physics, Toruń DHP network admin
e-mail: Janusz.U...@bofh.org.pl WWW: http://eris.phys.uni.torun.pl/~alex/
Płynąć chcę na Wschód, za Suez, / gdzie jest dobrem każde zło /
Gdzie przykazań brak dziesięciu / a pić można aż po dno.
Ja:
>> Ale kto Unikod będzie suportować, jeżeli nikt go nie będzie używał?
Gwidon Naskrent <nask...@hoth.amu.edu.pl>:
GN> Zle przedmowce zrozumiales. Unikodu _mozna_ uzywac do pisania po
GN> polsku (wylacznie), tylko po co?
No właśnie, więc ludzie nie używają. Więc nie ma motywacji, żeby
Unikod implementować. Na przykład w Emacsie. (Ale też, dajmy, w
takim Netscape, gdzie implementacja Unikodu jest bardzo prymitywna.
Właściwie tylko stosowna do systemów pisania greckopodobnych (G, Ł, C)
oraz ideograficznych (C, J, K, W).
>> [2] A co z Emacsem? Może nie powinienem Wam o tym mówić, ale od dwóch
>> lat trwają na ten temat rokowania. Po każdej rundzie dochodzi się do
>> tego samego wniosku -- wszyscy, ze Stallmanem włącznie, uważają że
>> jest to świetny pomysł, ale wszyscy czekają aż się kto inny za to
>> weźmie.
GN> To sie chyba impas nazywa?
Owszem. Deadlock zostanie zlikwidowany gdy komuś Unikod w Emacsie tak
się stanie potrzebny, że się za to weźmie. A póki pisanie w Unikodzie
się nie rozpowszechni, nie ma na to szansy.
GN> No i oczywiscie kwestia fontow, ale to juz inna sprawa.
Nie zakładasz chyba, że aplikacja która wewnętrznie działa w Unikodzie
musi teksty wyświetlać za pomocą fontów Unikodowych? (Wiem, że nie
zakładasz, pamiętasz naszą dyskusję o Netscape?)
Jednakowóż, applikacje unikodowe łatwiej jest pisać w obecności fontów
unikodowych. Fontów takich jest już dość dużo:
1. Markus Kuhn z grupą wolontariuszy wzięli się za uzupełnianie
wszystkich standartowych fontów X-owych (tych w ISO 8859-1) do sporego
podzbioru Unikodu; fonty te są standartem w XFree86 3.9.15. Odsyłam
do
http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
2. Wszystkie fonty TrueType[1] (oraz OpenType/TTF i OpenType/CFF) są
wewnętrznie unikodowe. Xfsft opcjonalnie udostępnia je jako fonty
unikodowe.
3. Fonty CID można dość łatwo udostępnić jako unikodowe, i renderer
CIDFont w XFree86 3.9.15 opcjonalnie udostępnia je jako takie.
4. W przyszłości, xfsft będzie też udostępniał fonty Type 1 jako
unikodowe, ale czekam na razie na FreeType 2.0.
Pozdrawiam,
J.
Offtopic: Pamiętasz może, że kiedyś mnie przekonywałeś że xfsft
powinien przekodowywać w locie też fonty bitmapowe (miałeś rację, ja
byłem w błędzie). Odkąd Markus zrobił te czcionki ma to naprawdę
sens, więc się za to wziąłem.
[1] Poza starszymi fontami od Apple-a.
JU> Od kiedy TeX (ale ten prawdziwy a nie Omega) jest unikodowy ?
Chodziło oczywiście o Omegę, która jest jak najbardziej prawdziwa.
J.
> Filtrowanie prostego Unikodu (dokładnie, ISO 10646 poziom 1) nie jest
> specjalnie trudniej zrobić niż filtrowanie ISO 8859-2. Pełny Unikod
> jest owszem trudniej zaimplementować, ale przecież nie o to nam
> chodzi.
Tylko że efekty tego są takie, że mamy później napis "to i to używa
Unicode", a przy bliższym przyjrzeniu się okazuje się, że używa, ale tylko
pierwszych 300-40-600-900 (wstawić dowolną liczbę 255 < x < 2048) znaków, a
i to nie w 100% poprawnie.
To tak jak z tymi wszystkimi konwerterami tekstów, które konwertują między
ISO 8859-2 a CP 1250, ale... tylko polskie znaki!
Poza tym do sensownej zabawy z Unicode brak jest porządnych fontów (wiem,
Cyberbit, Everson Mono, blah blah).
Na łyndzie 2000 będzie dostępny, a w Office 2000 na przykład już jest
dostępny Arial Unicode MS, ręcznie pohintowany (na ekran) font Monotype'u
zawierający glify wszystkich znaków Unicode 2.1.
Mając taki font można się bawić w Unicode...
--
Pozdrawiam,
Adam Twardoch <adam.t...@euv-frankfurt-o.de>
> [2] A co z Emacsem? Może nie powinienem Wam o tym mówić, ale od dwóch
> lat trwają na ten temat rokowania. Po każdej rundzie dochodzi się do
> tego samego wniosku -- wszyscy, ze Stallmanem włącznie, uważają że
> jest to świetny pomysł, ale wszyscy czekają aż się kto inny za to
> weźmie. (Ja też.)
:-)
Dziwię się w takim razie, że pomylone ISO-2022 im się chciało...
Tymczasem pod Linuxa oprócz bardzo kiepskiego steda pojawił się
niewiele lepszy mined. Na pierwszy rzut oka niczego nie można w nim
konfigurować (drugi raz na razie nie rzucałem). No ale ma UTF-8, więc
jeśli ktoś koniecznie musi coś wyedytować... Do wygodnego pisania po
polsku AFAIK należałoby sporządzić osobną unikodową mapę klawiatury
i ręcznie ją przełączać. Edytor uwzględnia tylko ISO-8859-1, UTF-8
i UTF-16. Na terminalu nie-UTF-8 wszystkie znaki spoza ISO-8859-1
są wyświetlane jako ¤. Zaleta tego edytora: jest bardzo mały (kilka
plików *.c).
From: Thomas...@sietec.de
Newsgroups: comp.os.linux.announce
Subject: mined - versatile "simple" text mode editor; opt. mouse & menus
Date: Mon, 9 Aug 1999 19:23:17 GMT
Message-ID: <pycola.9342...@revelation.bak.helsinki.fi>
-----BEGIN PGP SIGNED MESSAGE-----
Mined 98 is hereby released to the internet public.
An editor that is small and simple to use but yet full of capabilities.
For those who remember or still use it: The previous version of mined
was the one I released in September 1995 ("sixth public release").
Highlights
- ----------
UTF-8 Unicode support:
* Works with UTF-8 text mode terminals or windows like xterm.
* Auto-detection of Latin-1, UTF-8 or UTF-16 input encoding.
* Commands and input support for display and handling of code values.
* Transparent handling of illegal UTF-8 sequences.
* Can edit UTF-8 text in non-UTF terminals.
* (Can, of course, also edit Latin-1 text in UTF-8 terminals.)
User interface:
* Intuitive, simple way of operation. No modes.
Intuitive cursor position handling, no weird limitations (e.g. at line-end)
or insert/append confusion.
* "Geometric" control-key layout for basic cursor movements (also known
as "WordStar" layout). (Cursor keys can be used as well, of course.)
* Use of a "HOP" key which amplifies any subsequent movement command
(and some other commands) in an intuitive sense. This way, a lot of
functions can be achieved quickly without remembering as many
control or function keys.
On a numeric keypad, the middle "5" key is used for this function in
order to gain a lot of very quickly-typed navigation commands.
(Function similar to WordStar's control-Q)
* Two key commands (starting with escape key) for less frequent functions.
* Mouse control available (xterm).
* Pull-down menus and a quick pop-up menu available.
* View only and restricted modes.
* Additional 8 bit character input and output support for uncapable
terminals (additional to being 8-bit clean, of course).
Composition function for accented characters.
* Optional support of mixed 8/16-Bit character sets.
Works with the Chinese xterm (cxterm).
Screen interaction:
* Perfect responsiveness to terminal/window size changes. On resizing
the window, mined will immediately adjust and update its display -
the text cursor position will stay where it was.
Resizing also works while prompting for input (e.g. search text).
(In the MSDOS version, there is a slight limitation when font
substitution TSRs like VGAMAX (recommended!) change the screen size;
in this case, mined will react after the next keystroke. Explicit
resizing commands are available in the MSDOS version, too).
* MSDOS version works at arbitrary size screens (especially extended text
modes like e.g. 132x44). (Of course, the Unix version works at any size
anyway.)
Mined also respects your colour settings.
* Nice screen output starting from current position and growing to the
top and bottom (useful with slow terminal connections for quick
visual focus on cursor position).
This option can even be enforced by slight output delay as it appears
to more naturally suggest to the users where they are.
* Display of filename and modification status in window header line and icon.
* Optional indication of line-end, TAB characters, and long line shift-out.
* Proportional screen font support prepared.
* Wordstar-compatible keyboard layout option (in addition to basic
cursor movement which always uses "topographic layout"). This option
includes some WordStar compatibility command supplements.
* Optional exchange of function attachments to Backspace and Delete keys.
* Function key sequences for many common terminal types are always activated
(vt100, vt100 application mode, Sun, various xterm settings, Linux console,
HP and Iris workstation X windows, PC keyboard) - I know termcap is
supposed to handle this but often many function keys are not configured;
also remote Unix operation from a PC should thus be enabled.
* The MSDOS version has a few screen mode switching functions
(e.g. increase/decrease of vertical or total screen size).
Secure text and file handling:
* Consequent checking of any loss of text risk:
* In any case of file writing or other text saving problem
mined will continue the editing session instead of exiting.
* No external file other than the original source of the text
being edited will be overwritten without confirmation by any
text or buffer save operation.
* No accidental quit without prompting for any unsaved changes.
* All file handling errors are reported quoting clear error indications
(in contrast to the cryptic messages of all those classic Unix tools...)
* In case of external interrupts, panic handling attempts to save text
to a panic file.
Text editing features:
* Word/line wrap with left/right margins and first line indentation.
(Uses either empty lines or blank/non-blank line ends as paragraph
indications.)
* Paste between different (including subsequent) sessions of mined.
* Cut/Copy/Paste/Copy to file/Paste from other session functions
with optional append mode.
* Insert command for HTML commands.
* Multiple text position markers.
Search functions:
* Search/replace with optional interactive confirmation.
Extended search functions:
* Search function for identifier at current cursor position.
* Search function for matching parenthesis.
* Repeat function for the two previous search operations.
* Startup search expression on command line.
* Startup option for line number positioning.
Other useful features:
* Optional memory of last cursor position when a file save command is issued,
automatic re-positioning in next editing session.
* Change of file name / working directory association while editing.
* Editing within pipe option (Unix version).
* Suspend function (^Z) with autosave.
* Unix/DOS/Mac Line-end conversions.
Portability:
* Runs on Unix and MSDOS, used to run on VMS which I cannot check any more.
* Should compile on any Unix version - if there are problems, please ask me.
Download
- --------
Download is available from the HTML version of this information at
http://www.inf.fu-berlin.de/~wolff/mined.html
- -----------------------------------------------------------------------------
Thomas Wolff
http://www.inf.fu-berlin.de/~wolff/
to...@computer.org
- --
This article has been digitally signed by the moderator, using PGP.
http://www.iki.fi/mjr/cola-public-key.asc has PGP key for validating signature.
Send submissions for comp.os.linux.announce to: linux-a...@news.ornl.gov
PLEASE remember a short description of the software and the LOCATION.
This group is archived at http://www.iki.fi/mjr/linux/cola.html
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
iQCVAgUBN68qpVrUI/eHXJZ5AQEN4gP/RiNuX8QdqBo44Eghm3K17abFDYbuhXvX
2OfPoMpR76z2wmUyezmozApb7VfkAnTHgmVI2VTFVqMzkH6rLWhwXyA43wx6sPlW
dB1V+TGbKWpz/TSCMLe4RDZX2VPFtZkKIdaRK9bj/U83Ulc+JjIRrGh3Vq0RR0nd
qkguf098S34=
=z9s5
-----END PGP SIGNATURE-----
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://kki.net.pl/qrczak/
\__/ GCS/M d- s+:-- a22 C+++>+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
> Od kiedy TeX (ale ten prawdziwy a nie Omega) jest unikodowy ?
BTW, kiedyś próbowałem obejrzeć Omegę i nic z tego nie wyszło -
AFAIR nie udało mi się uzyskać żadnych cirkawych znaków spoza ASCII.
Czy to jest już w ogóle działający produkt?
> GN> Zle przedmowce zrozumiales. Unikodu _mozna_ uzywac do pisania po
> GN> polsku (wylacznie), tylko po co?
>
> No właśnie, więc ludzie nie używają. Więc nie ma motywacji, żeby
Uzywaja, ale nie do tego! Naprawde nie umiesz rozgraniczyc kiedy Unikod
nalezy, mozna i nie trzeba zastosowac?
> takim Netscape, gdzie implementacja Unikodu jest bardzo prymitywna.
> Właściwie tylko stosowna do systemów pisania greckopodobnych (G, Ł, C)
> oraz ideograficznych (C, J, K, W).
Coz, Misie gora :->
Co nie znaczy ze Netszkapa nie rozumie innych unikodowych encji - niestety
wersje 4.x maja przykrego buga uniemozliwiajacego mieszanie kodowan.
> GN> No i oczywiscie kwestia fontow, ale to juz inna sprawa.
>
> Jednakowóż, applikacje unikodowe łatwiej jest pisać w obecności fontów
> unikodowych. Fontów takich jest już dość dużo:
To zalezy od, ahem, formatu.
> 1. Markus Kuhn z grupą wolontariuszy wzięli się za uzupełnianie
> wszystkich standartowych fontów X-owych (tych w ISO 8859-1) do sporego
> podzbioru Unikodu; fonty te są standartem w XFree86 3.9.15. Odsyłam
> do
>
> http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html
Bitmapowe = brzydkie, poza tym robienie takiego fontu w kilku
rozdzielczosciach to katorga. No i oczywiscie nie ma mowy nie tylko o CJK,
ale rowniez o devangari, oriya i tym podobnych zawijasach (wiem, bo
probowalem robic konsolowy font devangari).
> 2. Wszystkie fonty TrueType[1] (oraz OpenType/TTF i OpenType/CFF) są
> wewnętrznie unikodowe. Xfsft opcjonalnie udostępnia je jako fonty
> unikodowe.
Trzeba jeszcze aplikacji ktora bedzie chciec je poprawnie obslugiwac
(powiedzmy ze yudit sie nadaje).
> 3. Fonty CID można dość łatwo udostępnić jako unikodowe, i renderer
> CIDFont w XFree86 3.9.15 opcjonalnie udostępnia je jako takie.
Bije sie w piersi ze wstydu, ale co to jest CID?
> 4. W przyszłości, xfsft będzie też udostępniał fonty Type 1 jako
> unikodowe, ale czekam na razie na FreeType 2.0.
Uuu, czy format Type 1 jest naprawde wart rozwijania? Bo ja widze ze
przynajmniej w kwestii polskich znakow sa spore problemy z implementacja.
> Offtopic: Pamiętasz może, że kiedyś mnie przekonywałeś że xfsft
> powinien przekodowywać w locie też fonty bitmapowe (miałeś rację, ja
> byłem w błędzie). Odkąd Markus zrobił te czcionki ma to naprawdę
> sens, więc się za to wziąłem.
Nic nie pamietam, ale milo slyszec :-)
GSN
>
> To tak jak z tymi wszystkimi konwerterami tekstów, które konwertują między
> ISO 8859-2 a CP 1250, ale... tylko polskie znaki!
Bo one sa temu dedykowane (tfu!), albo autorowi nie chcialo sie dodawac
wiecej. Tak czy owak w pewnym sensie one wystarczaja.
> Poza tym do sensownej zabawy z Unicode brak jest porządnych fontów (wiem,
> Cyberbit, Everson Mono, blah blah).
Lepszy rydz niz nic.
> Na łyndzie 2000 będzie dostępny, a w Office 2000 na przykład już jest
> dostępny Arial Unicode MS, ręcznie pohintowany (na ekran) font Monotype'u
> zawierający glify wszystkich znaków Unicode 2.1.
Jejku, juz sie slinie... ciekawe ile to bedzie zajmowac :)
GSN
> BTW, kiedyś próbowałem obejrzeć Omegę i nic z tego nie wyszło -
Ja tez, ja tez - dokumentacja jest k***owa; jak niby mam uzywac tych
fontow *.ocp?
GSN
>> [2] A co z Emacsem? Może nie powinienem Wam o tym mówić, ale od dwóch
>> lat trwają na ten temat rokowania. Po każdej rundzie dochodzi się do
>> tego samego wniosku -- wszyscy, ze Stallmanem włącznie, uważają że
>> jest to świetny pomysł, ale wszyscy czekają aż się kto inny za to
>> weźmie. (Ja też.)
> :-)
> Dziwię się w takim razie, że pomylone ISO-2022 im się chciało...
> Tymczasem pod Linuxa oprócz bardzo kiepskiego steda pojawił się
> niewiele lepszy mined. Na pierwszy rzut oka niczego nie można w nim
Vim to tyż będzie miał. Obsługę unikodu, znaczy.
pzdrwm,
Jubal
--
,.--. [http://abyss.lodz.pdi.net/~baran/ = mailto:ba...@knm.org.pl]
/o`,- ). -------------------------------------------------------------
(_,.'-'rs [Mirosław L. Baran = Jubal = medical student = ALCHEMY PANY!]
Life is a yo-yo, and mankind ties knots in the string.
Dla mnie prawdziwy -> oparty na słynnej implementacji Knutha. Która o
ile pamiętam jest zamknięta, tj nie wolni w niej nic zmieniać.
>Na łyndzie 2000 będzie dostępny, a w Office 2000 na przykład już jest
>dostępny Arial Unicode MS, ręcznie pohintowany (na ekran) font Monotype'u
>zawierający glify wszystkich znaków Unicode 2.1.
>
>Mając taki font można się bawić w Unicode...
do pisania artykułów niusowych ? toć tu wystarczy dowolny font zawierający wystarczająco duży podzbiór unikodu
> > To tak jak z tymi wszystkimi konwerterami tekstów, które konwertują
między
> > ISO 8859-2 a CP 1250, ale... tylko polskie znaki!
> Bo one sa temu dedykowane (tfu!), albo autorowi nie chcialo sie dodawac
> wiecej. Tak czy owak w pewnym sensie one wystarczaja.
No tak, ale ja już wolę pełną obsługę ISO 8859-x niż obsługę unikodu taką
jak w tych konwerterach.
> Jejku, juz sie slinie... ciekawe ile to bedzie zajmowac :)
24,131,012 bajty
A po skonwertowaniu do XMLa ok. 180 MB :) Bardzo fajnie się edytuje taki
plik :)
--
Pozdrawiam,
Adam Twardoch <adam.t...@euv-frankfurt-o.de>
> > Bo one sa temu dedykowane (tfu!), albo autorowi nie chcialo sie dodawac
> > wiecej. Tak czy owak w pewnym sensie one wystarczaja.
>
> No tak, ale ja już wolę pełną obsługę ISO 8859-x niż obsługę unikodu taką
> jak w tych konwerterach.
Sa konwertery i konwertery. Ty decydujesz i wybierasz najlepsze :)
> 24,131,012 bajty
<przewraca oczami>
Ciekawe jak dlugo bedzie sie to ladowac do FCP? Piec minut?
> A po skonwertowaniu do XMLa ok. 180 MB :) Bardzo fajnie się edytuje taki
> plik :)
Zaraz, jakiego XMLa?
GSN
>> No właśnie, więc ludzie nie używają [Unikodu]. Więc nie ma
>> motywacji,
GN> Uzywaja, ale nie do tego! Naprawde nie umiesz rozgraniczyc kiedy
GN> Unikod nalezy, mozna i nie trzeba zastosowac?
Umiem. Na przykład, Unikod byłoby wygodnie użyć w każdym tekście
który zawiera ,,cytaty'', -- albo innego typu punktuację. Unikod
byłoby wygodnie użyć w każdym tekście w którym pisze się o sercu po
Francusku (a nie mówcie mi, że `oe' to tylko ligatura).
Aby to było możliwe, obsługa unikodu powinna być mniej więcej tak
rozpowszechniona jak obsługa ISO 8859-2. Tak, niestety, narazie nie
jest. Wina, oczywiście, nasza, Emacsowców (i tak nie chcę być czytany
przez ludzi nie używających Emacs-a).
Co nie znaczy, oczywiście, że tekst który można wyrazić w ISO 8859
powinien być kodowany w Unikodzie.
>> takim Netscape, gdzie implementacja Unikodu jest bardzo prymitywna.
>> Właściwie tylko stosowna do systemów pisania greckopodobnych (G, Ł, C)
>> oraz ideograficznych (C, J, K, W).
O Netscape pisałem, bo czytałem źródła. Nie wierzę aby inne browsery
były lepsze.
GN> Coz, Misie gora :->
Chcesz powiedzieć, że Misie implementują coś poza ISO 10646 Level 1,
nawet gdy działają na Amerykańskiej Windzie (nie Windows 1901, tylko
NT lub 98)? Jeśli tak, to bardzo chciałbym wiedzieć.
(Konkretne pytania: czy umie prawidłowo wyświetlić tekst Arabski
zakodowany bez form prezentacyjnych? Tekst w Hindi? Albo nawet, co
jest znacznie prostsze, tekst Thai? Hebrajski jest nie na temat, bo o
ile wiem zawsze jest kodowany z formami prezentacyjnymi.)
GN> Bitmapowe = brzydkie, poza tym robienie takiego fontu w kilku
GN> rozdzielczosciach to katorga.
Chodzi głównie o zrobienie fontu który można użyć jako `fallback' --
piszesz sobie w normalnym Lucida Typewriter, nagle przychodzi list z
Maroka, i znagi Tamazight są automatycznie wyciągnięte z `fixed'.
Brzydkie, bo brzydkie, ale Tamazight jest czytelny, i zaraz możesz
wysłać odpowiedź (po Polsku, naturalnie), że /takich/ robaczków to Ty
jeszcze nie widziałeś.
GN> Trzeba jeszcze aplikacji ktora bedzie chciec je poprawnie obslugiwac
Przepraszam, ale dyskusja nam się rozkłada. Przypominam gdzie stoimy:
Ja: Brak aplikacji.
Ty: No to co że brak, jeśli nie ma fontów.
Ja: Fonty są, brak aplikacji.
>> 3. Fonty CID można dość łatwo udostępnić jako unikodowe, i renderer
>> CIDFont w XFree86 3.9.15 opcjonalnie udostępnia je jako takie.
GN> Bije sie w piersi ze wstydu, ale co to jest CID?
Format używany przez Adobe dla fontów daleko Wschodnich. Fonty CID
zawierają takie same glify jak fonty PostScriptowe (Type 1, Type 3,
Type 32 lub Type 42), ale zamiast nazw glifów mają numeryczne
identyfikatory. Obejrzyj `Far Eastern Font Pack' dla Acrobat-a 4.0
(dostępny bez $$$) (uwaga, tuzin megabajtów).
GN> Uuu, czy format Type 1 jest naprawde wart rozwijania?
Tak. Jest on dobrze udokumentowany (w odróżnieniu od TrueType),
dobrze zrozumiany (w odróżnieniu od TrueType), prosty w implementacji
(w odróżnieniu od TrueType), zwarcie koduje informację (w odróżnieniu
od TrueType) i nie podlega żadnym patentom (sytuacja prawna TrueType w
niektórych krajach nie jest jasna). Jakość jest niewiele gorsza od
TrueType jeśli używa się dobrego rasteryzatora (tego od Adobe, nie
tego w X-ach).
Odsyłam do
http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/renderers.html
dla porównania jakości. Nota bene: porównanie używa najlepszych
istniejących fontów TrueType-owych, więc jest niesprawiedliwe (wiele
fontów Type 1 ma podobną jakość do tych w tym przykładzie, natomiast
jest niewiele tak dobrych fontów TrueType).
GN> Bo ja widze ze przynajmniej w kwestii polskich znakow sa spore
GN> problemy z implementacja.
Jakie? Jedyne problemy które znam są wyłącznie spowodowane głupotą
programistów, a nie jakością samego formatu.
Pozdrawiam,
J.
al...@eris.phys.uni.torun.pl (Janusz A. Urbanowicz):
JU> Dla mnie prawdziwy -> oparty na słynnej implementacji Knutha.
O ile wiem, Omega jest częściowo oparta na TeX-u. (Nie wiem tylko w
jak wielkiej części.)
JU> Która o ile pamiętam jest zamknięta, tj nie wolni w niej nic
JU> zmieniać.
Implementację Knutha wolno modyfikować. Jedynym warunkiem jest że
jeżeli zmodyfikowana werja nie zdaje ``Trip Test'', czyli nie jest
identyczna z TeX-em, to nie może być nazwana `TeX'. Warunek ten
zobowiązuje też samego Knuth-a.
Na przykład, implementacja TeX-a dla tekstu dwukierunkowego, choć
napisana przez samego Knuth-a, nazywa się `TeX-XeT', nie `TeX'.
Podobna sytuacja jest z fontami `CM', których zmodyfikowana wersja
nazywa się `EC'.
Pozdrawiam,
J.
Napisz 8 i kopnij, a zobaczysz, ile.
U mnie FCP sie oczywiscie zawiesza...
> > A po skonwertowaniu do XMLa ok. 180 MB :) Bardzo fajnie się edytuje taki
> > plik :)
>
> Zaraz, jakiego XMLa?
> JU> Dla mnie prawdziwy -> oparty na słynnej implementacji Knutha.
>
> O ile wiem, Omega jest częściowo oparta na TeX-u. (Nie wiem tylko w
> jak wielkiej części.)
>
> JU> Która o ile pamiętam jest zamknięta, tj nie wolni w niej nic
> JU> zmieniać.
>
> Implementację Knutha wolno modyfikować. Jedynym warunkiem jest że
> jeżeli zmodyfikowana werja nie zdaje ``Trip Test'', czyli nie jest
> identyczna z TeX-em, to nie może być nazwana `TeX'. Warunek ten
> zobowiązuje też samego Knuth-a.
TeX "prawdziwy" nie jest oparty na implementacji Knutaha,
ale po prostu nią jest. A sprawdza się to właśnie "Trip Testem"
czyli po prostu kompilując plik trip.tex, gwarantuje on uzyskanie
jednakowych danych wyjściowych na podstawie tego samego
manuskryptu. A implementacja ta, czyli plik tex.web, nie jest
zamknienta (niech nam D.E.K żyje jak najdłużej) tylko
ograniczona z góry numerem wersji, który to jest rosnący
i zbieżny do liczby $\pi$. Ta, której obecnie używam, 35. z kolei,
z marca 1995 ma numer 3.14159.
Jedyną poważną zmianą było wprowadzenie 8-bitowego
manuskryptu w wersji 2.992 (mimo, że często kojarzy się to
z przejściem do wersji 3).
> Na przykład, implementacja TeX-a dla tekstu dwukierunkowego, choć
> napisana przez samego Knuth-a, nazywa się `TeX-XeT', nie `TeX'.
> Podobna sytuacja jest z fontami `CM', których zmodyfikowana wersja
> nazywa się `EC'.
Nie tyle zmodyfikowana, co rozszerzona. Modyfikacje też miały
miejsce, ale to inna sprawa. A rozszerzenie polega dodaniu 128
dodatkowych znaków.
Właśnie z TeXowymi fontami sprawa wygląda najciekawiej.
Mimo, że dzisiaj używa się najczęściej 8-bitowych, to nic
nie stoi na przeszkodzie aby miały więcej niż 256 znaków.
Nie ma to nic wspólnego z formatem manuskryptu. Nawet
siedmiobitowy TeX mógł takich używać. Zresztą nawet
dzisiaj wielu użytkowników (czego ja z kolei nijak pojąć nie
mogę) używa "ciachowego" inputu opartego na podstawowym
ASCII.
A co do samego Unicodu w TeXu, to raczej nie widzę potrzeby
modyfikacji. Lepiej chyba napisać preprocesor zamieniający
Unicode na ASCII strawny dla TeXa. Być może ten preprocesor
też mógłby być napisany w TeXu, ale tu nie jestem pewien, bo
nigdy nie miałem potrzeby używanie Unicode (Omega to dla
mnie także temat nieznany).
--
Jarek
> > Zaraz, jakiego XMLa?
>
> http://www.letterror.com/ttx/
Eee, tylko na Mace...
GSN
> Umiem. Na przykład, Unikod byłoby wygodnie użyć w każdym tekście
> który zawiera ,,cytaty'', -- albo innego typu punktuację. Unikod
> byłoby wygodnie użyć w każdym tekście w którym pisze się o sercu po
> Francusku (a nie mówcie mi, że `oe' to tylko ligatura).
Byloby wygodnie i ladnie, ale niekonieczne. Cycaty i myslniki mozna
przedstawic w ASCII, oe podobniez. W przypadku gdyby owo oe mialo sie
pojawic w tekscie raz, uzycie Unikodu uznalbym za watpliwe.
> Aby to było możliwe, obsługa unikodu powinna być mniej więcej tak
> rozpowszechniona jak obsługa ISO 8859-2. Tak, niestety, narazie nie
> jest. Wina, oczywiście, nasza, Emacsowców (i tak nie chcę być czytany
> przez ludzi nie używających Emacs-a).
Akurat emacs nie pozostaje w tyle za vimem (ktory tez nie radzi sobie
z UTF-8, czy ogolnie z kodowaniami wielobajtowymi).
> Co nie znaczy, oczywiście, że tekst który można wyrazić w ISO 8859
> powinien być kodowany w Unikodzie.
O to wlasnie mi chodzilo! Przy zastrzezeniu ze "mozna wyrazic" odnosi sie
takze do czesci znakow typograficznych i akcentow.
> GN> Coz, Misie gora :->
>
> Chcesz powiedzieć, że Misie implementują coś poza ISO 10646 Level 1,
> nawet gdy działają na Amerykańskiej Windzie (nie Windows 1901, tylko
> NT lub 98)? Jeśli tak, to bardzo chciałbym wiedzieć.
Misie gora dlatego ze pozwalaja uzywac na stronie kodowanej w ISO-8859-x
&encji; jako znakow ISO-8859-1. Szkapa zamiast nich pokazuje znaki
zapytania - obserwuje ten smutny fakt w kilku kolejnych wersjach od 4.0.
Oczywiscie Unikod dziala tu i tu, ale...
> (Konkretne pytania: czy umie prawidłowo wyświetlić tekst Arabski
> zakodowany bez form prezentacyjnych? Tekst w Hindi? Albo nawet, co
> jest znacznie prostsze, tekst Thai? Hebrajski jest nie na temat, bo o
> ile wiem zawsze jest kodowany z formami prezentacyjnymi.)
Nie wiem, nie uzywam tych jezykow. Przypuszczam ze potrafi, o ile te
formy sa na odpowiednich miejsach w foncie (najnowsze core fonts M$ maja
juz te tablice GL czy jak to sie tam, wiec moze MSIE 5.0 potrafi zrobic
z nich uzytek).
> Chodzi głównie o zrobienie fontu który można użyć jako `fallback' --
Fallbacki tez musza byc ladne :)
> piszesz sobie w normalnym Lucida Typewriter, nagle przychodzi list z
> Maroka, i znagi Tamazight są automatycznie wyciągnięte z `fixed'.
> Brzydkie, bo brzydkie, ale Tamazight jest czytelny, i zaraz możesz
> wysłać odpowiedź (po Polsku, naturalnie), że /takich/ robaczków to Ty
> jeszcze nie widziałeś.
Wlasnie, co to jest Tamazight? Tego nie ma w blokach unikodowych :-)
> GN> Uuu, czy format Type 1 jest naprawde wart rozwijania?
>
> Tak. Jest on dobrze udokumentowany (w odróżnieniu od TrueType),
> dobrze zrozumiany (w odróżnieniu od TrueType), prosty w implementacji
> (w odróżnieniu od TrueType), zwarcie koduje informację (w odróżnieniu
> od TrueType) i nie podlega żadnym patentom (sytuacja prawna TrueType w
> niektórych krajach nie jest jasna). Jakość jest niewiele gorsza od
> TrueType jeśli używa się dobrego rasteryzatora (tego od Adobe, nie
> tego w X-ach).
Oraz nie ma do niego porzadnego. darmowego, edytora (w odroznieniu od
TrueType :>
> GN> Bo ja widze ze przynajmniej w kwestii polskich znakow sa spore
> GN> problemy z implementacja.
>
> Jakie? Jedyne problemy które znam są wyłącznie spowodowane głupotą
> programistów, a nie jakością samego formatu.
No to poradz jak szybko i bezbolesnie przekodowac setki spapranych fontow
Type1 na Unicode?
GSN
GN> Oraz nie ma do [Type 1] porzadnego. darmowego, edytora (w
GN> odroznieniu od TrueType :>
Przepraszam, a do TrueType, to jaki jest? (Przypominam, że Softy nie
jest ani darmowy, ani porządny -- nie obsługuje wogóle instrukcji.)
Niezły jest FontLab, częściowo obsługujący TT oraz T1 (T1 nie całkiem
zupełnie -- o ile wiem, brak mu flex i counter control; flex co prawda
jest rzadko potrzebny, a counter control jest tylko użyteczny do
ideografów). Kosztuje z paręset zielonych, ale jest wersja darmowa
wersja demo (która tylko pozwala na cztery zapisy -- potem trzeba
instalować od nowa).
(Adamie, byłbym wdzięczny gdybyś mógł w tej dyskusji wyrazić opinię;
znasz się na tym znacznie lepiej ode mnie.)
Dobrego, darmowego edytora TT nie będzie nigdy, i to z bardzo prostego
powodu: instruktowanie TT (równoważność hintingu) jest czarną magią.
Natomiast hinting T1 jest dość łatwy i dobrze zrozumiały... więc gdyby
ktoś się za to wziął, to w kilka miesięcy możnaby...
GN> No to poradz jak szybko i bezbolesnie przekodowac setki spapranych
GN> fontow Type1 na Unicode?
Może niedługo... (nic narazie nie mówię)
Serdecznie pozdrawiam,
J.
P.S. Aha, i jeszcze jedno: dyskusja na temat xfsft o której wcześniej
wspomniałem była z Qrczakiem, nie z tobą.
/.../
>
>Niezły jest FontLab, częściowo obsługujący TT oraz T1 (T1 nie całkiem
>zupełnie -- o ile wiem, brak mu flex i counter control; flex co prawda
>jest rzadko potrzebny, a counter control jest tylko użyteczny do
>ideografów). Kosztuje z paręset zielonych, ale jest wersja darmowa
>wersja demo (która tylko pozwala na cztery zapisy -- potem trzeba
>instalować od nowa).
Pragnę Sprostować pewien szczegół - prawdopodobnie pomyliłeś FontLab-a
z TypeTool - FontLab w wersji demo nie umożliwia eksportu, natomiast
obostrzenie do 4-krotnego generowania fontu dotyczy właśnie
TypeTool-a. Tak btw, FontLab ma możliwość pracy w trybie wsadowym,
posiada także tabele kodowań, więc konwersja ma szansę zostać
przeprowadzona w miarę bezboleśnie (piszę "w miarę", gdyż np. fonty
Bitstream/Theta są deklarowane jako "symbol", a to może bruździć.
/.../
ALex
> GN> Oraz nie ma do [Type 1] porzadnego. darmowego, edytora (w
> GN> odroznieniu od TrueType :>
>
> Przepraszam, a do TrueType, to jaki jest? (Przypominam, że Softy nie
> jest ani darmowy, ani porządny -- nie obsługuje wogóle instrukcji.)
FCP... tak mi sie palnelo ze darmowy, bo dostalem od autora rejestracje
na wersje 1.x i 2.x w zamian za znaczny support i wazeline ;-)
> P.S. Aha, i jeszcze jedno: dyskusja na temat xfsft o której wcześniej
> wspomniałem była z Qrczakiem, nie z tobą.
Milo mi tym niemniej :)
GSN
> > http://www.letterror.com/ttx/
>
> Eee, tylko na Mace...
Przeciez to jest napisane w Pythonie! (www.python.org)
Napisz do autora, ze chcesz wersje zródlowa TTXa, to ci przysle. Ja uzywam
tego na Windows 98 i Windows 2000 RC1 i dziala bez problemu...
> Dobrego, darmowego edytora TT nie będzie nigdy, i to z bardzo prostego
> powodu: instruktowanie TT (równoważność hintingu) jest czarną magią.
Mylisz się. Połączenie FCP i MSVTT daje fantastyczne i niedrogie stanowisko
pracy:
Font Creator Program ($35)
http://www.high-logic.com/fcp.html
Microsoft Visual TrueType (darmowy dla profesjonalistów)
http://www.eu.microsoft.com/typography/tools/vtt.htm
Jest też przecież mnóstwo darmowych programów firmy Apple, w tym darmowy
edytor RoyalT:
http://fonts.apple.com/
> Niezły jest FontLab, częściowo obsługujący TT oraz T1 (T1 nie całkiem
> zupełnie -- o ile wiem, brak mu flex i counter control; flex co prawda
> jest rzadko potrzebny, a counter control jest tylko użyteczny do
> ideografów).
> (...) hinting T1 jest dość łatwy i dobrze zrozumiały... więc gdyby
> ktoś się za to wziął, to w kilka miesięcy możnaby...
Hi hi... Przyznasz mi chyba rację Juliuszu, że ludzie, którzy wiedzą, kiedy
używać flex i counter control, używają innych narzędzi... Albo mogą wręcz
pisać bezpośrednio w kodzie...
Ja na przykład używam FontLaba do produkcji fontu Type 1, zaś końcową
kontrolę robię w Noah, który pozwala mi pracować "blisko" kodu Type 1. Tam
też można dodwać np. dodatkowe instrukcje hintujące.
Noah: http://sites.netscape.net/noahtm/
Notabene: autor Noah (Węgier ukrywający się pod pseudonimem Yeah Noah)
napisał ten program w Visual Basicu 3.0. Pisał do mnie, że przydałby mu się
jakiś zdolny matematyk do współpracy (on sam np. nie miał pomysłu jak zrobić
wypełnianie obrysów).
To pewnie kwestia przyzwyczajenia. Boguś Jackowski (http://www.bop.com.pl/
na swoich stronach używa nawet trzech kodowań polskich liter: ISO Latin-2,
polskawy i właśnie ciachowy.
To tak jak używanie polskiej klawiatury z prefiksem zamiast z Altem i
programów typu Polkeyb...
>
> Przeciez to jest napisane w Pythonie! (www.python.org)
Z deszczu pod rynne... probowalem Pythona pod Winde i nic :(
> Napisz do autora, ze chcesz wersje zródlowa TTXa, to ci przysle. Ja uzywam
> tego na Windows 98 i Windows 2000 RC1 i dziala bez problemu...
Tak sie zastanawiam - do czego to jest przydatne poza wyswietlaniem
tablic fontow w Misiach (ktorych nie mam)?
GSN
Ale żeby napisać porządną obsługę Unicode, to trzeba mieć też odpowiedni
font. Poza tym Arial Unicode MS jest fantastycznie pohintowany na ekran
(bardziej jak Verdana niż jak zwykły Arial), więc można stworzyć sobie np.
ładne bitmapy choćby Softym czy Pyrus FONmakerem...
Słaboś próbował... Ja zainstalowałem wszystko to, co mi kazał zainstalować
Just van Rossum w instrukcji i -- chodzi jak burza.
> Tak sie zastanawiam - do czego to jest przydatne poza wyswietlaniem
> tablic fontow w Misiach (ktorych nie mam)?
Jak to do czego? Możesz edytować dowolny font w kodzie źródłowym. Jeżeli np.
chcesz zmienić wartość pola fsSelection w tablicy OS/2, to TTX jest jedynym
narzędziam, które ci to umożliwia.
Poza tym dużo można się nauczyć o strukturze wewnętrznej fontu, oglądając go
w ten sposób. Można poeksperymentować...
> Jak to do czego? Możesz edytować dowolny font w kodzie źródłowym. Jeżeli np.
> chcesz zmienić wartość pola fsSelection w tablicy OS/2, to TTX jest jedynym
> narzędziam, które ci to umożliwia.
A co robi to pole i dlaczego jedynym narzedziem?
> Poza tym dużo można się nauczyć o strukturze wewnętrznej fontu, oglądając go
> w ten sposób. Można poeksperymentować...
Uhm, widzisz, sa i tacy ktorzy GIFy pisza w vi...
GSN
> Jaroslaw Sokolowski <ja...@janski.edu.pl> wrote in message
> news:37B45CD6...@janski.edu.pl...
> > Zresztą nawet
> > dzisiaj wielu użytkowników (czego ja z kolei nijak pojąć nie
> > mogę) używa "ciachowego" inputu opartego na podstawowym
> > ASCII.
>
> To pewnie kwestia przyzwyczajenia. Boguś Jackowski (http://www.bop.com.pl/
> na swoich stronach używa nawet trzech kodowań polskich liter: ISO Latin-2,
> polskawy i właśnie ciachowy.
>
> To tak jak używanie polskiej klawiatury z prefiksem zamiast z Altem i
> programów typu Polkeyb...
A ja właśnie klawiaturą dawno temu leczyłem (objawowo)
pare osób używających notacji ciachowej. Napisałem
drajwer do klawiatury posługujący się slashem jako prefixem.
Instalowało się to potajemnie na komputerze pacjenta.
Można było obserwować ciekawe reakcje gdy ktoś zobaczył
na ekranie to, czego się nie spodziewał, choć w głębi duszy
pragnął ujrzeć.
Poza tym w Twojej wypowiedzi nie bardzo rozumiem użycie
słowa "zamiast". Ja uczyłem się pisania na maszynie (marki
Mercedes, ale jak najbardziej przystosowana przez
przedwojennych mechaników do pisania po polsku)
mniejwięcej równocześnie z pisaniem ręcznym.
Jak wiadomo nawyki nabyte we wczesnym dzieciństwie
są najtrwalsze, tak więc w moim przypadku prościej było
zmodyfikowanie systemów operacyjnych kolejnych komputerów.
Zresztą, tam za Odrą pewnie łatwiej Ci moje podejście zrozumieć ;-)
Co do strony BOP, to ten _wybór_ bardzo sympatyczny
i sentymentalny, tylko czemu kodowanie - jak to określiłeś -
polskawe (CP-1250) jest tam domyślne?
A przyzwyczajenie? nie bardzo wierzę. Ja tam jestem
przyzwyczajony do wygody czytania czegoś takiego jak łódź,
już /l/od/x, "l"od'z, czy lodz jest dla mnie "wygodne inaczej".
Ale nie takie dziwactwa jestem w stanie tolerować...
TeXnicznie pozdrawiam
Jarek
> > Jak to do czego? Możesz edytować dowolny font w kodzie źródłowym. Jeżeli
np.
> > chcesz zmienić wartość pola fsSelection w tablicy OS/2, to TTX jest
jedynym
> > narzędziam, które ci to umożliwia.
> A co robi to pole i dlaczego jedynym narzedziem?
No, ustawia pewne parametry fontu, nieważne, akturat taki przykład wybrałem.
W czasie tworzenia fontu TrueType (a tym bardziej OpenType) trzeba bardzo
uważać na to, co gdzie się wstawia. Tym bardziej, jeżeli przygotowuje się
fonty do specjalnych celów.
Nie istnieje edytor TrueType, który by obsługiwał wszystkie aspekty fontu.
Tym bardziej nie istnieje na razie żaden wizualny edytor OpenType. Np.
FontLab nie ma i bardzo długo nie będzie miał ani pełnego edytora hintingu,
anie tym bardziej hintingu odcieni szarości. Nie ma też edytora bitmap
zaszytych w tabeli SBIT fontu TrueType (które są prostszym niż hinting
sposobem uzyskania ładnych znaków na ekranie).
Dlaczego jedynym narzędziem? Dlatego, że większość narzędzi wizualnych
najpier dekompiluje font do swojego wewnętrznego formatu, a potem (przy
zapisie) kompiluje go na nowo według swoich algorytmów. Tzn., że efekt
wyjściowy *zawsze* będzie różny od wejściowego. Fonty TrueType mogą mieć np.
specyficzne podprogramy rysowania glifów, stosować kompresję glifów itp.,
ale FontLab, RoyalT, SplineLab, Fontographer, Font Creator, Softy itp. albo
usuwają część tych informacji (bo ich nie "rozumieją"), albo też sprowadzają
to postaci uproszczonej. No i w efekcie, nawet gdybyś chciał zmienić tylko
jedno pole w foncie, efekt końcowy staje się zupełnie inny od początkowego,
obniża się jego oryginalna jakość.
Inaczej, gdy przekonwertujesz font do XMLa. Możesz wówczas zmienić dowolne
pole (np. Dodać jakiś przyrostek do nazwy rodziny), a następnie
przekonwertować XML z powrotem na TrueType. W efekcie powstanie niemal
idealny klon fontu wyjściowego, jedynie o zmienionej nazwie -- ponieważ przy
konwersji TTXem font jest interpretowany sekwencyjnie i nie ma tu zbyt
daleko idącej interpretacji semantycznej.
W każdym razie ja uważam, że program Justa van Rossuma zmienił świat
typograficzny w stopniu nie mniejszym niż FreeType (swoją drogą Just
wykorzystał kod FreeType w TTXie). Wreszcie jest sens czytać specyfikację
formatu!
> Uhm, widzisz, sa i tacy ktorzy GIFy pisza w vi...
Nie, to nie to. Ja bym to porównał do czegoś innego -- są tacy, którzy
rysują wykresy w Corelu i są tacy, którzy je programują w Metapoście.
TrueType to praktycznie język programowania. Za dużo tam różnorodnych typów
danych, algorytmów itd., by móc przyrównywać go do GIFa.
A swoją drogą, gdyby ktoś mi zaproponował dobrą wizualizację formatu GIF w
XML, to czemu nie? Zresztą, format SVG (Scalable Vector Graphics) to właśnie
tego typu pomysł -- czyż nie?