mek 2.0-s formátumok

[Zsadányi Nagy Csaba]

Sziasztok!

nagyon-nagyon régen írtam, de azért rendszeresen olvaslak titeket.
a mek-ben tárolt fileformátumokkal kapcsolatban szeretnék néhány
észrevételt tenni.

az első, a pdf:
a pdf writer makró valóban nem a legjobb minőségű, sőt, erős gyanúm,
hogy nem is legális az 'ingyenes használata'. a teljes adobe acrobat
doboz, amit oktatási intézmények (ebbe az oszk is belefér) részére 10
fölhasználós liszensszel adják 100eFt körül. ebben benne van a
distsiller, és nekem a teljesen hagyományos arial meg akármilyen wines
szemi-unicode fontokat is jól kezelte, persze ttf-beágyazással. a
minősége is háromféle lehet (szemben a pdf writerrel), "nyomdai",
nyomtatásra ill. képernyőre szánt. egyetlen gáz, hogy 32bites winen megy
a program, nem úgy, mint az acrobat reader, tehát pdf készítéshez kell
egy windowsos gép.


és most akkor a 2.0 mek html javaslatai:

> - Lehetőleg ne használjunk böngészőfüggő HTML-címkéket és
> speciális  eszközöket: stíluslapokat (CSS), szerver-oldali
> beillesztést (SSI), parancs- és programnyelveket (JavaScript,
> CGI, PHP, Java, Flash stb.), helyzetérzékeny térképeket
> (image-map).

ebből a listából a css-t szerintem ki kell húzni, ugyanis a lehető
legkevésbé böngészőfüggő! sokkal inkább böngésző és
operációsrendszer-függő a <font xxx=""></font>, ezek használata helyett
kellene a css-t minél intenzívebben használni.

> - A dokumentumban található rajzokhoz, képletekhez, képként
> bevitt táblázatokhoz, különleges betűtípussal készült
> feliratokhoz stb. 16 vagy 256 árnyalatú, non-interlaced,
> 89-es verziójú (szükség esetén transzparens) GIF formátumot
> célszerű használni. A PNG formátum nem ajánlott, mert a
> régi böngészők nem ismerik.

a gif helyett is igenis érdemes volna a png-re áttérni, lévén az
előzővel 'kopirályt-viták' voltak/vannak, egy csomó linuxos disztribbe
helyből nem is támogatott éppen ezért.

> - A fejlécben fel kell tüntetni az ékezetes betűkhöz használt
> kódolást ("iso-8859-2") és a magyar nyelv kódját ("hu"). Vagyis:
> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
> <meta http-equiv="Content-Language" content="hu">
[...]
> - A Windows Latin-2-es (8859-2) kódkészletével kell írni az ékezetes
> betűket, nem használunk "acute"-kódolást, mert megnöveli a méretet
> és rosszul olvashatóvá teszi a file-t.

na ez így nagyon-nagyon ellentmondásos! egyrészt törekszünk a
szabványosságra, másrészt meg nem? egy baromi egyszerű kis szkripttel
bármikor lehet szabványos szekvenciákkal lekódolt html szöveget
windowsos textté varázsolni, de csak elég megnézni, hogy például az
[alt]+0148 karakterkombináció milyen gyönyörű üres négyzetecskeként
jelenik meg 4.0-s explorer fölött iso-8859-2vel (win 1250-nel már
tényléeg záró idézőjel, de ez megint nem szabványos). nem azt mondom,
hogy legyen követelmény az "acute"-kódolás, de inkább ez legyen a
támogatott

> Nem használjuk ki a 8859-2
> kódtábla és a HTML egyéb speciális karaktereit sem, mivel ezek nem
> biztos, hogy helyesen jelennek meg minden böngészőben,

pedig nem lehet lespórolni a &copy; vagy &#169; megoldást, ha csak nem
akarunk visszatérni a (c) régi txt-s "kalligrammák" világába. a html nem
forrás olvasására van kitalálva, imho, aki meg keresőt ír, az tudna a
szabványos megoldással is dolgozni.

> illetve a teljesszövegű keresőt is megzavarják. (Az idézőjeleket
> egyszerű " karakterrel kell írni az idézet elején és végén egyaránt,
> a belső idézőjeleket >> illetve << jelekkel, a gondolatjeleket egy
> egyszerű - jellel, a félbehagyott mondatot jelző három pontot pedig
> igy: ... )

ennél még a linuxos két vessző alulra, írógép idézőjel fölülre is jobb,
hihetetlen szenvedés kitakarítani egy html file-ból a kezdő, záró
idézőjel helyettis használt "-jeleket, nem is beszélve arról, hogy
magukban a html elemekben is éppen eleget fordul elő.

> folyamatos szövegeknél (pl. regények) a <p align=justify> opció
> ajánlható, mert így szebb az összhatás. A bekezdések elejére nem
> kell behúzást csinálni (pl. egy kis képpel vagy &nbsp; kódokkal),
> a jó olvashatósághoz elegendő a <p> által létrehozott távolság a
> bekezdések között.

ezek css1-gyel mind-mind gyönyörűszépen megoldhatók, pl:

<p style="text-align:justify; text-indent:5%">

ömagában a <p></p> által határolt bekezdések távolsága is böngészőfüggő,
éppenhogy a stíluslap teszi egyértelművé:

<p style="text-align:justify; text-indent:5%; margin-top:1em;
margin-bottom:0.5em">

> - Verseknél és rövid felsorolásoknál a <br> címkével kell lezárni
> a sorokat (a versszakok között egy további <br> kell). Ha beljebb
> is akarjuk rendezni ezeket a sorokat, akkor a <dir> címkét használjuk.

<p style="text-align:justify; text-indent:0%; margin-left:2em;
margin-top:1em; margin-bottom:0.5em">
és sorok végén <br>

> - Kérdés, hogy milyen megoldást használjunk a nem magyar betűkre?
> A MEK szövegekben előfordulhatnak pl. francia, spanyol, cirill,
> görög, román, szláv karakterek. Korábban mindenféle trükköket
> használtak ilyenkor a Web-mesterek. Ma úgy tűnik, hogy az
> UTF-8 kódolás terjed leginkább, de ezt egyrészt nehéz kódolni,
> másrészt csak a legújabb böngészők ismerik és a kereső programok
> sem kezelik. Én inkább az NCR (Numeric Character Representation)
> megoldást javaslom, amikor a karakter Unicode-ját decimális
> formában írják be "&#" után (pl. a cirill "ju" betű: &#1070; ).

a charset=utf-8 beírása esetén tökéletesen használhatók a decimális
kódok.
igazából a szimpla magyar szövegek esetében is érdemes volna előbb-utóbb
áttérni az utf-8/16-ra, mert ez egy életre véget vet a kalapos u
hullámos o keverésének azzal, hogy a 336-337 ill. a 368-369-re teszi az
Ő-ő Ű-ű-t.

egyszóval, csak annyit javasolnék, hogy ha már váltani akar a mek, új
normákat kidolgozni, akkor ne gyakjuk meg a html4 és xhtml1 szabványt.
ezek éppen az egyértelmű megjelenítést biztosítják. és html source !=
txt file, ezt sem szabad elfelejteni, erre lehet megfelelő szkripteket
írni, ha éppen ez szükséges, de a txt file sok esetben lebutítás a
html-hez képest.

Zsadányi Nagy Csaba
zsadanyi at tarki.hu