Thanks Hans for your response, Hans Hagen wrote:

Vit Zyka wrote:

...

Hi Hans,

Jaroslav Hajtnar (in czech TeX list) encountered the problem with \input primitive redefinition. He uses a macro package for comma separated value file (CSV) inclusion. It redefines some catcodes and \endlinechar before start reading such file by \input. The problem is that during reading CSV the reading is interrupted by reading another file like

\readfilename ->pdfr-ec (c:/TeXLive2005/texmf-context-a/tex/context/base/pdfr-ec.tex

ConTeXt macro \input takes care about catcodes but not about \endlinechar so in this situation the file pdfr-ec is read with wrong \endlinechar which causes error.

We believe that system solution is the ConTeXt takes care about \endlinechar when automatically starts reading some standard files. Please Hans can you look at it?

works ok here; i remember an issue but that was solved already (afaik); tex live 2005 is not that up to date -)

I did not test this with such museum-belonging ConTeXt. The problem preserves in the latest public version 2007-04-17. See very left bottom corner attached PDF (mkii).

a workaroun din an old version is to load pdfr-ec manually, so that it's read already when the cvs code shows up

We internally solve the problem (temporary redefining \input) but I believe that ConTeXt should follow more systemic solution.

in scancvs ... beware of redefining such core macros

yes, we did not want you solve possible problems of an usage such external (plain TeX designed) macros---only if we believe that the behavior looks like a ConTeXt bug and that can cause problems for other users.

in the latest version there are things like \pushcatcodes ... \popcatcodes and catcode tables (a simulation of the native luatex catcode table features);

I will look at this. But I have not entered a catcode problem in this case.

fyi: in luatex (and therefore context mkiv) doing things with data files will be easier

can you test with a recent context?

yes, it did not work, see attached files.

(there is a cvs module btw)

thanks for a remmembering. As I said: this mail is a suggestion to solve a general problem by systemic way. Thanks Vit

Hans Hagen wrote:

Vit Zyka wrote:

...

thanks for a remmembering. As I said: this mail is a suggestion to solve a general problem by systemic way.

sure, but \input cannot be redefined in a robust way because of its scanning nature; ok, in luatex we can intercept things, but not in mkii Hans

I thought that the number of calling \input inside text state is limited---(only?) one example is a loading encoding definition file. Why not to incorporate the cleverness of setting a default \endinputchar to a macro that invokes \input?

\startreadingfile ... \stopreadingfile is an option then

understand as a solution bypassing \input redefinition Vit

Hans Hagen wrote:
> Vit Zyka wrote:
>> Hans Hagen wrote:
>>> Vit Zyka wrote:
>>>>
>>>> thanks for a remmembering. As I said: this mail is a suggestion to 
>>>> solve a general problem by systemic way.
>>>>
>>> sure, but \input cannot be redefined in a robust way because of its 
>>> scanning nature; ok, in luatex we can intercept things, but not in mkii
>>> Hans
>>
>> I thought that the number of calling \input inside text state is 
>> limited---(only?) one example is a loading encoding definition file. 
>> Why not to incorporate the cleverness of setting a default 
>> \endinputchar to a macro that invokes \input?
>>
>>> \startreadingfile ... \stopreadingfile is an option then
>>
>> understand as a solution bypassing \input redefinition
> it all depends on the usage ...
> - most commands use \readfile, or \readjobfile or alike - when loading 

yes, in this case \readsysfile inside:

\def\dododoincludepdffontresource#1% encoding
   {\bgroup
    \edef\currentencoding{#1}%
    \doifvaluesomething\pdffontfileresource
      {\startreadingfile
         \ignorelines % just in case \par is redefined;
 
\readsysfile{pdfr-\getvalue\pdffontfileresource}\donothing\donothing
       \stopreadingfile
       \letgvalue\pdffontfileresource\empty}%
    \egroup}

> modules of system files , we revert to tex catcode regimes etc
> user files ... well, here tex (context) does not know what is dealt 
> with; take xml, in that case we want to stay in xml mode; or verbatim, 
> which needs to set up verbatim
> actually this is all arranged already (and always has been)

catcodes yes, but \endlinechar not:

\def\startreadingfile% beter een every en \setnormalcatcodes
   {\doglobal\increment\readingfilelevel
    \the\everystartreadingfile
    \beginrestorecatcodes
    \setcatcodetable\prtcatcodes}

why not introduce something like

    \beginrestoreendlinechar

???

Vit

> your problem with the pdfr-enc file results from the fact that loading 
> that file comes at a nasty moment and afaik loading now happens under 
> the right regime; so, if there's a problem we need to find out what's 
> the problem with that file, since it's unrelated to \input (loading 
> that  vector is managed so to say)


> Hans

Dear All, After having had a great deal of problems when submitting my context files to my publisher, I decided to write future projects in docbook (V4.4), rather than switching to Word or Open Office. From the docbook files I then can generate an rtf or wml file which is much more of use for the publisher, alas. For me this has the extra advantage of viewing the text in an xml editor, such as Xmlmind. My new docbook document processes well in Context and no errors are reported, thanks again Simon and others for this valuable application. However two major problems have come up. The first is a problem with Cals tables and figures: 1. After the section containing a table, all section headings in the following chapters, sections, subsections, even bridgeheads, until the end of the document are omitted, without due error message. 2. Figure titles create an extra section or subsection title. I solved this by using <informalfigure> instead and inserting a <caption>. For tables using caption is not an option. A second problem is the language label. In the top level of the tree, I add the language label, e.g. <book lang="nl">. In general, and for fo processors this is, I believe the right place. Context gives the following error message: \dodosetupsometextprefix ...malist [#3]\docommand \else \def \docommand ##1{... l.53 \XMLDBheadtext[nl]{figuren}{Figuren} This disappears when the label (lang="nl") is removed. Perhaps I am not right in putting the language label in this way, if so, please advise. I am grateful for any help, Robert

Well, you know: the publisher preferred a word document or rtf; he was quite puzzled by the Context codes. I then had to convert the text to xml, which he was more acostumed to. Robert luigi scarso schreef:

On 6/4/07, R. Ermers wrote:

...

Dear All,

After having had a great deal of problems when submitting my context files to my publisher,

What kind of problems ?

Dear All, I made a test file. Run the file bndel-xml.tex. The pdf file was too big for the list, even zipped, so I copied parts of it in a text file. Robert

On 6/7/07, R. Ermers wrote:

Dear All,

Has anybody found time to dive into the docbook-Context problem?

The problem is that all section headings dissappear when in a given docbook section a table is placed. (Of course the document is validated against the dtd.) it's in my todo list.e that But I can't see it until Saturday

I am really puzzled by it, and it prevents me from using Context now.

Please,note that you can always use the standard chain xml:xslt ->[xsltproc] ->tex:tex->[context]->pdf and with texexec one can "hide xsltproc" For sure there is a pdf about that at pragma. -- luigi ---------------------------------------------------------------- If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net

Quoting "R. Ermers" :

Thank you very much indeed, Luigi.

I have been looking at the xml manuals of Pragma. I don't quite understand what you mean with the standard chain.

Hans has a This Way on using xsltproc to generate ConTeXt code, which you can then process using context. I do not know if there is a docbook xsl file with all the translations, or will you have to do that by hand. Aditya

I have been experimenting before with docbook -> fo, and fop, and I came across valuable programs like Docman and Gemdoc. But I still prefer the Context output.

I understand the mappings, but the Cals table mappings are more complicated. (This is also explained by Simon Pepping http://www.ntg.nl/maps/pdf/29_7.pdf) Perhaps this bug arose in a recent version of Context?

Robert

luigi scarso schreef:

...

On 6/7/07, R. Ermers wrote:

...

Dear All,

Has anybody found time to dive into the docbook-Context problem?

The problem is that all section headings dissappear when in a given docbook section a table is placed. (Of course the document is validated against the dtd.) it's in my todo list.e that But I can't see it until Saturday

I am really puzzled by it, and it prevents me from using Context now.

Please,note that you can always use the standard chain xml:xslt ->[xsltproc] ->tex:tex->[context]->pdf and with texexec one can "hide xsltproc"

For sure there is a pdf about that at pragma.