typeseting XML

typeseting XML

[Petr Ferdus]

Hi,
how could be typeset backslash character parsed from XML stream?
I tryed:

\defineXMLsingular [backslash]  {$\backslash$}

having in XML doc an  empty element <backslash/>, with no success (no
error either, it was just silently discarded). 

Also, would it be possible to have # char in the name of XML entity? Like:

\defineXMLentity [#937] {$\Omega$} %instead of
\defineXMLentity [937] {$\Omega$} 

because it seems to be rather conforming to naming convention of entities
based on unicode position  of its glyph (&#937; in this case).

Thanks very much.

Petr Ferdus

Re:typeseting XML

[Petr Ferdus]

> \defineXMLsingular [backslash]  {$\backslash$}
> having in XML doc an  empty element <backslash/>, with no success (no
> error either, it was just silently discarded). 
Sorry for bothering, there was a mistake on my side. This setup of course
typesets backslash, just my script was converting to elements everything
but backslashes...

Anyway I have another question. There was a note on direct XML processing
(texexec --env=yourenvironemntfile yourfile.xml) which works partly for me.
I can't force source document translation. I used to have in tex source 
files line like:
%interface=en output=pdf texttranslate=cp1250cs
When I try direct XML processing and have such line in my environment
file, it seems to ignore such directive (I guess, because it produces dvi
file without explicit command line switch). What could be done to inform
context about XML source encoding? (command line swich like
--translate-file=cp1250cs, process instruction or specifying  used
encoding directly in XML source does not seem to help as well) Any input
would be appreciated.

If I can have one more question, I would like see some hints, how to
implement separate handling of XML elements,  based on the value in
key="value" pairs. So if there is an element <p style="a"> what would
process p's separately for every value of style key. Is there some
shareable knowledge? (I can't figure it out with the aid of "example"
manual)
Thanks.

Peter Ferdus

Re: typeseting XML

[Johannes Hüsing]

Hi all,

coming across a problem with encoding I searched my private 
mailing list archive and found this question:

On Thu, May 17, 2001 at 01:54:54AM +0200, Petr Ferdus wrote:
[...]
> Also, would it be possible to have # char in the name of XML entity? Like:
> 
> \defineXMLentity [#937] {$\Omega$} %instead of
> \defineXMLentity [937] {$\Omega$} 
> 
> because it seems to be rather conforming to naming convention of entities
> based on unicode position  of its glyph (Ω in this case).
> 

That would be a feature I would value very much. Has this been accomplished 
already? I see ConTeXt in a quite confused state about the hash sign when 
I try the above.

Greetings

Johannes
-- 
Johannes Hüsing   There is something fascinating about science. One gets
hannes@ruhrau.de  such wholesale returns of conjecture from such a 
                  trifling investment of fact.                Mark Twain

Re: typeseting XML

[Hans Hagen]

At 08:51 PM 2/3/2002 +0100, Johannes Hüsing wrote:
>Hi all,
>
>coming across a problem with encoding I searched my private
>mailing list archive and found this question:
>
>On Thu, May 17, 2001 at 01:54:54AM +0200, Petr Ferdus wrote:
>[...]
> > Also, would it be possible to have # char in the name of XML entity? Like:
> >
> > \defineXMLentity [#937] {$\Omega$} %instead of
> > \defineXMLentity [937] {$\Omega$}
> >
> > because it seems to be rather conforming to naming convention of entities
> > based on unicode position  of its glyph (Ω in this case).
> >
>
>That would be a feature I would value very much. Has this been accomplished
>already? I see ConTeXt in a quite confused state about the hash sign when
>I try the above.

hashes are very special to tex, and once they end up in macro bodies they 
spontaniously replicate etc etc

i even think (but taco should confirm that) that once the # is in the line 
buffer, there is no way to get rid of the # message

Hans

-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

Re: typeseting XML

[Taco Hoekwater]

Hi Hans,

Hashes are very weird things, true. But the problem shouldn't occur.
ConTeXt should insert a hashmark behind the scenes as soon as it discovers
that the entity starts with a '9', or balk with an error message
about an invalid entity.

Entities that do not start with # are named entities, as opposed to
character references. And names are not allowed to start with a number.

Therefore, "&937;" is not valid XM. "Ω" is the correct way.

Allowed alternative notations are "Ω" and "Ω".

All may have any number of leading zeroes, and the XML spec also
states that the character referenced itself should be a valid XML character
(so � is also illegal)

It would be much cleaner if there was a new command \defineXMLchar,
that takes a number as argument instead of a csname string. Then the
Context XML parser could have support for all of the possible inputs.

Greetings, Taco

On Tue, 05 Feb 2002 09:26:13 +0100
"Hans Hagen" <pragma@wxs.nl> wrote:

> hashes are very special to tex, and once they end up in macro bodies they 
> spontaniously replicate etc etc

-- 
groeten,

Taco

Re: typeseting XML

[Hans Hagen]

At 02:20 PM 2/5/2002 +0100, Taco Hoekwater wrote:

>Hashes are very weird things, true. But the problem shouldn't occur.

indeed, so Taco (and other tex-hackers), how about this:

\unprotected \def\bla{\bgroup\catcode`\#=\@@ignore\dobla}
\def\dobla[#1]{\egroup\dorecurse{#1}{hello }} \bla[#123]

\unprotected \def\bla{\bgroup\catcode`\#=\@@space\dobla}
\def\dobla[#1]{\egroup\dorecurse{#1}{hello }} \bla[#123]

 > .....

ok, i will look into that later (error messages/recovery and such, since i 
have to look into chars anyway).

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                                   fall-back web server: 
www.pragma-pod.nl
-------------------------------------------------------------------------

Re: typeseting XML

[Johannes Hüsing]

On Tue, Feb 05, 2002 at 02:20:28PM +0100, Taco Hoekwater wrote:
> Therefore, "&937;" is not valid XM. "Ω" is the correct way.

ok, so for the moment I could just filter out all hash signs of my 
XML source and I'll be fine.

> 
> Allowed alternative notations are "Ω" and "Ω".

Yes, and I used hex codes and wrote a small emacs function that 
replaced it by single chars, but after Perl's XML::DOM parsed it
they were turned into decimals :-(

Thanks very much

Johannes
-- 
Johannes Hüsing   There is something fascinating about science. One gets
hannes@ruhrau.de  such wholesale returns of conjecture from such a 
                  trifling investment of fact.                Mark Twain

Re: typeseting XML

[Hans Hagen]

At 01:07 AM 6/15/01 +0200, Petr Ferdus wrote:
>Is it already possible to break natural tables on page boundaries? After
>some tries (being appetized by natural table manual), I have found remark
>in core-ntb which says that break over page is  on TODO list.
>Is there any progress in this area or what would be the options with XML
>processing? 

still on the todo list 

Hans
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: typeseting XML

[Petr Ferdus]

Is it already possible to break natural tables on page boundaries? After
some tries (being appetized by natural table manual), I have found remark
in core-ntb which says that break over page is  on TODO list.
Is there any progress in this area or what would be the options with XML
processing? 

Would be very appreciated.

Thank you.

Peter

Re: typeseting XML

[Petr Ferdus]

On Mon, 4 Jun 2001, Hans Hagen wrote:
> well, define own macros as 
> 
>   \unexpanded\def\blabla{ some \rubish\ commands } 
> 
> also, use 
> 
>   \definehead[MySection][section]
> 
> and try 
> 
>   \setuphead[MySection][expansion=yes|command|no]

Haven't had much success with this. For now I am changing source data
(just three occurences in text), hoping to tackle it later.

Peter

Re: typeseting XML

[Hans Hagen]

At 10:03 AM 6/1/01 +0200, Petr Ferdus wrote:
>On Thu, 31 May 2001, Hans Hagen wrote:
>
>> >(1)also if there is an entity at the beginning of element passed
>> >by argument (example in XML data).
>> 
>> dontknow/dontsee, anyway i'll send you the latest xtag files [there is also
>> a new \defineXMLenv..push one you may want to use]
>
>Right  placement of \appendtoks ...  sequence with expansion of
>list makes them nicely expand. Thank you very much. 
>
>Unafected remains only case (1) than means, if one line of XML data in
>gtest example would look like:
><h2>&amp;Title H2 with any entity an the very beginning of it</h2>
>
>which is processed by some macro e.g.:
>\long\def\MySection#1{\section{#1}}% which could do more, would it had
>                                   % chance
>and declared as:
>\defineXMLargument [h2] {\MySection}
>
>it produces "! Incomplete \ifnum; error.  ..."
>
>(data from elements, which have no macros hooked to their processing, do
>process correctly)

well, define own macros as 

  \unexpanded\def\blabla{ some \rubish\ commands } 

also, use 

  \definehead[MySection][section]

and try 

  \setuphead[MySection][expansion=yes|command|no]

Hans

-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: typeseting XML

[Petr Ferdus]

On Thu, 31 May 2001, Hans Hagen wrote:

> >(1)also if there is an entity at the beginning of element passed
> >by argument (example in XML data).
> 
> dontknow/dontsee, anyway i'll send you the latest xtag files [there is also
> a new \defineXMLenv..push one you may want to use]

Right  placement of \appendtoks ...  sequence with expansion of
list makes them nicely expand. Thank you very much. 

Unafected remains only case (1) than means, if one line of XML data in
gtest example would look like:
<h2>&amp;Title H2 with any entity an the very beginning of it</h2>

which is processed by some macro e.g.:
\long\def\MySection#1{\section{#1}}% which could do more, would it had
                                   % chance
and declared as:
\defineXMLargument [h2] {\MySection}

it produces "! Incomplete \ifnum; error.  ..."

(data from elements, which have no macros hooked to their processing, do
process correctly)

Thanks

Peter

Re: typeseting XML

[Hans Hagen]

At 05:01 PM 5/30/01 +0200, Petr Ferdus wrote:
>Hi,
>In this example are processed data comming from XML source
>file. It typesets it mostly(1) in correct manner except processing
>lists (predefined or user defined). In that case  "raw" XML
>stream is used, which inflicts with  further processing of lists.

That will be handled automatically later, when i've added status info to
the tui/tuo files.   

\appendtoks \enableXMLelements \to \everyreadfile % test hack

will work for now, given that you use a recent version.

>(1)also if there is an entity at the beginning of element passed
>by argument (example in XML data).

dontknow/dontsee, anyway i'll send you the latest xtag files [there is also
a new \defineXMLenv..push one you may want to use]

> It is possible to persuade context to process lists in way, it
>processes text, so the expanded text would show up correctly, and
>all entities and singular elements would not bother processing
>and the links get resolved correctly? What should be done for it?

try: \setuplist[whatever][expansion=yes]
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: typeseting XML

[Petr Ferdus]

On Wed, 30 May 2001, Hans Hagen wrote:
> 
> \defineXMLenvironment [table] \bTABLE \eTABLE
> \defineXMLnested      [tr]    \bTR    \eTR
> \defineXMLnested      [td]    \bTD    \eTD
> 
> does the nesting, pretty dirty code btw
Thanks, it is as an example in "example" manual. It solves tables
quite nicely.

% Would be great to be able get some parameters as well.
% What makes next code fragment misbehave? (it doesn't place
% border aroud table, remapping \mapXMLvalue seems not to work)

%--interface=en --output=pdf --translate-file=cp1250cs
%% to run: texexec gtest2.tex

%tables
\defineXMLenvironment [table] {
%\bgroup
   \mapXMLvalue{table}{border}{0}{off}
   \mapXMLvalue{table}{border}{1}{on}
   XMLpar:\XMLpar{table}{border}{aaa}:\par
   XMLvar:\XMLvar{table}{border}{bbb}:\par
   XMLval:\XMLval{table}{border}{ccc}:\par
   %\bTABLE[frame=on]
   \bTABLE[frame={\XMLvar{table}{border}{ddd}}]
%\egroup
} {\eTABLE }%

\defineXMLnested [tr] \bTR \eTR
\defineXMLnested [td] \bTD \eTD

\starttext
some text

\enableXML
<table border='1' cellspacing='0' cellpadding='0'>
 <tr>
  <td valign='top'>
  <pMsoNormal>19.30 </pMsoNormal>
  </td>
  <td valign='top'>
  <pMsoNormal>dinner</pMsoNormal>
  </td>
 </tr>
 <tr>
  <td valign='top'>
  <pMsoNormal>20.00 </pMsoNormal>
  </td>
  <td valign='top'>
  <pMsoNormal>sight-seeing</pMsoNormal>
  </td>
 </tr>
</table>

<?context-command \stoptext ?>

Peter

Re: typeseting XML

[Hans Hagen]

At 04:05 PM 5/29/01 +0200, Petr Ferdus wrote:
>On Tue, 29 May 2001, Hans Hagen wrote:
>> Can you give an small example; do you use pprikazy nested? If so, then you
>> need the grouped approach. 
>> 
>> or play with \xdef\GCislo{\XMLpop{pprikazy} and alike 
>
>This element is not nested. But knowing how to solve nested case wouldn't
>hurt.

i come back to that later. 

\defineXMLenvironment [table] \bTABLE \eTABLE
\defineXMLnested      [tr]    \bTR    \eTR
\defineXMLnested      [td]    \bTD    \eTD

does the nesting, pretty dirty code btw

Hans

-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: typeseting XML

[Petr Ferdus]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 743 bytes --]

Hi,
In this example are processed data comming from XML source
file. It typesets it mostly(1) in correct manner except processing
lists (predefined or user defined). In that case  "raw" XML
stream is used, which inflicts with  further processing of lists.

(1)also if there is an entity at the beginning of element passed
by argument (example in XML data).

 It is possible to persuade context to process lists in way, it
processes text, so the expanded text would show up correctly, and
all entities and singular elements would not bother processing
and the links get resolved correctly? What should be done for it?

Many thanks in advance.

Peter

Attached: gtest.tex - test file
gtest__.xml - XML data source
gtest.pdf - resulting pdf file

[-- Attachment #2: Type: APPLICATION/ZIP, Size: 16777 bytes --]

Re: typeseting XML

[Petr Ferdus]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 364 bytes --]

On Tue, 29 May 2001, Hans Hagen wrote:
> Can you give an small example; do you use pprikazy nested? If so, then you
> need the grouped approach. 
> 
> or play with \xdef\GCislo{\XMLpop{pprikazy} and alike 

This element is not nested. But knowing how to solve nested case wouldn't
hurt.

Attached is a small example, with tiny XML source and resulting pdf.

Peter

[-- Attachment #2: Type: APPLICATION/ZIP, Size: 13166 bytes --]

Re: typeseting XML

[Hans Hagen]

At 10:27 AM 5/29/01 +0200, Petr Ferdus wrote:
>How to make \XMLerase to work? In construction like:
>\defineXMLenvironment[pprikazy]
>   {\bgroup
>   \defineXMLpush[pprikazy]
>   \XMLerase {pprikazy}}%first part end
> 
>  {%\defXMLstring \GCislo {pprikazy}
>   \egroup}%second part end
>
>one could (at least I did) expect to get rid of whatever stays between
><pprikazy></pprikazy> tags. Not the case. It gets happily typeset to
>ouput. Would be nice no know the way, how to prevent printing same
>elements and still have it somehow available (that what I thought would 
>\defXMLstring accomplish) (\XMLignore works, but the element is gone)

Can you give an small example; do you use pprikazy nested? If so, then you
need the grouped approach. 

or play with \xdef\GCislo{\XMLpop{pprikazy} and alike 

Hans
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: typeseting XML

[Hans Hagen]

At 06:15 PM 5/18/01 +0200, you wrote:
>On Fri, 18 May 2001, Hans Hagen wrote:
>
>> <...>bla \bla bla<...> should work ok
>
>It did not worked (and for some reason still doesn't) in my setup (source
>documents encoded in win1250), so I decided to contvert those characters
>which didn't show to singular elements. This way I get them in output.

i'm working on a simple perl xml-cleanup thing

Hans
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------

Re: typeseting XML

[Petr Ferdus]

On Fri, 18 May 2001, Hans Hagen wrote:

> <...>bla \bla bla<...> should work ok

It did not worked (and for some reason still doesn't) in my setup (source
documents encoded in win1250), so I decided to contvert those characters
which didn't show to singular elements. This way I get them in output.

Peter

Re: typeseting XML

[Hans Hagen]

At 01:54 AM 5/17/01 +0200, Petr Ferdus wrote:
>Hi,
>how could be typeset backslash character parsed from XML stream?

<...>bla \bla bla<...> should work ok

>I tryed:
>
>\defineXMLsingular [backslash]  {$\backslash$}
>
>having in XML doc an  empty element <backslash/>, with no success (no
>error either, it was just silently discarded). 

\defineXMLsingular [backslash] {\tex{}} 

i still need to add named chars for backslash and so. 

>Also, would it be possible to have # char in the name of XML entity? Like:
>
>\defineXMLentity [#937] {$\Omega$} %instead of
>\defineXMLentity [937] {$\Omega$} 
>
>because it seems to be rather conforming to naming convention of entities
>based on unicode position  of its glyph (&#937; in this case).

that's being worked on [for that taco and i need to have the math unicode
part finished]

Hans
-------------------------------------------------------------------------
                                  Hans Hagen | PRAGMA ADE | pragma@wxs.nl
                      Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------