[cstex] ConTeXt a plainovska makra a aplikace II.

[Vit Zyka]

Pekne odpoledne,

mne se onech pet znaku 0x18 zobrazi pri verzi

This is pdfTeXk, Version 3.141592-1.40.0-beta-20060213 (Web2C 7.5.5)
TeXExec | TeXExec | version 6.2.0 - 1997-2006 - PRAGMA ADE/POD
TeXExec | TeXUtil   | version 9.1.0 - 1997-2005 - PRAGMA ADE/POD
TeXExec | CtxTools | version 1.3.3 - 2004/2006 - PRAGMA ADE/POD
TeXExec |
TeXExec | testing interface en
TeXExec | ConTeXt ver: 2007.03.19 11:20 MKII fmt: 2007.4.10 int: 
english/english

Presnou pricinu neznam, ConTeXt prevadi znaky ^^X na znak s hodnotou 
0x18 pomoci \rawcharacter, takze i v logu je primo znak 0x18, viz
   http://zyka.net/tmp/demo1.zip

Znaky se NEzobrazi, kdyz zakomentaruji radek
   \scanbase demo.csv %
a nactu makra \input scancsv-context

Vit Zyka

Petr Olsak wrote:
> On Mon, 23 Apr 2007, Jaroslav Hajtmar wrote:
> 
>> Dobry den.
>> To, ze je pritomnost "chyby" zavisla na verzi ConTeXtu nebo PdfTeXu je
>> pro mne dobra zprava...
> 
> Dobry den,
> 
> ja nevim, jestli je to uplne jiste. Mame pouze jistotu, ze jeden
> ConTeXtista se pokusil chybu zrekonstruovat a nepodarilo se mu to.
> 
> Nemam ConTeXt, takze dale vyvozuji jen z toho, co mohu vykoukat z toho
> PDF. Ty nuly jsou jen zleva stinovane. Po prevodu toho PDF do
> PostScriptu a analyze te casti postscriptoveho kodu, ktera ty
> nuly produkuje, jsem zjistil, ze:
> 
> - cely dokument je tisten jedinym fontem LMRoman12-Regular vcetne tech nul,
> - nuly jsou vytisteny drive nez cokoli ostatniho na strance,
> - nuly jsou tisteny kodem 030 osmickove, 0x18 hexa, 24 dekadicky, tj.
>   jedna se o znak ^^X, coz v kodovani Cork je znak tvorici cast znaku
>   procento nebo promile (viz napr. TST, str. 288).
> 
> Puvodne jsem si myslel, ze problem bude v tom, ze behem vystupni rutiny
> ConTeXt nacita nejake sve pracovni soubory, a protoze ma zmenenu v danem
> okamziku sadu kategorii, dopadne vystup jinak.
> 
> Ted se spis priklanim k tomu, ze za to muze separator ^^X, ktery jsem ve
> svem makru scancsv pouzil. Tento znak (mimo rozsah viditelnych ASCII
> znaku) jsem pouzil proto, aby nedoslo ke kolizi s beznym vstupnim textem
> v CVS souboru, kde takovy znak neocekavam.
> 
> Na zacatku definuji ve svem makru scancsv (pouze pro jistotu):
> 
> \catcode`\^^X=13 \def^^X{}
> 
> a v okamziku cinnosti \scanbase lokalne nastavuji
> 
> \endlinechar=`\^^X
> 
> abych mohl nakrmit parametry maker jednotlive radky separovane ^^X.
> 
> V csplainu neni problem, nikde ve vystupu se (pri \tracingall)
> neobjevi v logu vystup tvaru
> 
> {the character ^^X}
> 
> takze i kdyby makra nespravne zafungovala a uteklo nejake ^^X, pak diky
> tomu, ze je  \catcode`\^^X=13 \def^^X{}, se do vystupu nic nedostane.
> 
> Domnivam se, ze ConTeXt asi meni kategorii znaku ^^X zpet na normalni
> a pak se ten znak dostane nejakou cestou do vystupu. V kterem okamziku,
> nevim, je to mozne zjistit nastavenim \tracingall a spustenim toho
> ConTeXtu (coz ja nemohu).
> 
> Zjistil jsem jeste, ze i kdyz zakomentuji bezpecnostni pojistku
> \catcode`\^^X=13 \def^^X{}, tak stejne mi zadne ^^X do vystupu v csplainu
> neutece. Je to mozna nadbytecna bezpecnostni pojistka, ktera navic v
> ConTeXtu nezafungovala.
> 
> Prosim ConTeXtisty, aby se na to podivali. Docela me to zajima, kde je
> problem.
> 
> Zdravim
> 
> Petr Olsak
> 
> 
> _______________________________________________
> csTeX mailing list
> csTeX at cs.felk.cvut.cz
> http://lists.felk.cvut.cz/mailman/listinfo/cstex
> 

-- 
=======================================================
Ing. Vít Zýka, Ph.D.                         TYPOkvítek

database publishing              databazove publikovani
data maintaining and typesetting in typographic quality
priprava dat a jejich sazba v typograficke kvalite

tel.: (+420) 777 198 189     www: http://typokvitek.com
=======================================================