Re: typeseting XML

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

[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

[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

[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]

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 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 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 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 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

very beta font switching/mapping

[Petr Ferdus]

While checking on very beta, I've been not able to produce searchable
pdfs. Is that ability already enabled there? I expect it could be,
based on the excerpt from mfonts-beta manual.

...or when some special output encoding is needed, for instance in pdf
annotations and/or unicode vectors that enable searching in documents.

If possible, can you please, provide some relevant information? (beta
works in this respect nicely) Thanks.

Peter

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

[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 - mixed buffers

[Petr Ferdus]

In case of using "regular" and "XML containing" buffers on the same page I
get "regular" one interpreted like XML (that means no TeX/Contex command
get executed and the whole content of "regular" is printed including
commands and comments stripped of "\" and "%{}" chars)

example of "regular" buffer
\startbuffer[MyRegular]
  \goto{Where to get...}[myfile::whereget]%this goes to footers on pages
  %by \setupfootertexts[{\getbuffer[MyRegular]}]
\stopbuffer

XML containting buffer
\startbuffer[MyXML]
\enableXML
<p>Here is a text spanning several pages, each of them except the last one
gets footer misinterpreted as XML.</p>
<p>More text...<p/>
<?context-command \disableXML?>
\stopbuffer

Is this somehow my fault or parsing gets mutally messed in the process?

Thanks 

Peter

Re: typeseting XML - mixed buffers

[Hans Hagen]

At 09:46 AM 6/27/01 +0200, Petr Ferdus wrote:
>In case of using "regular" and "XML containing" buffers on the same page I
>get "regular" one interpreted like XML (that means no TeX/Contex command
>get executed and the whole content of "regular" is printed including
>commands and comments stripped of "\" and "%{}" chars)
>
>example of "regular" buffer
>\startbuffer[MyRegular]
>  \goto{Where to get...}[myfile::whereget]%this goes to footers on pages
>  %by \setupfootertexts[{\getbuffer[MyRegular]}]
>\stopbuffer
>
>XML containting buffer
>\startbuffer[MyXML]
>\enableXML
><p>Here is a text spanning several pages, each of them except the last one
>gets footer misinterpreted as XML.</p>
><p>More text...<p/>
><?context-command \disableXML?>
>\stopbuffer
>
>Is this somehow my fault or parsing gets mutally messed in the process?

rather tricky what you're doing. 

ow about 

\startbuffer[blabla]
<p>more bla</p>
\stopbuffer

\processXMLbuffer[blabla]

or 

\startXMLcode [name]
.....
\stopXMLcode

\getXMLcode[name]

however, the best way to get thing into headers and footers is to use the
marking mechanism, where, in this case you need to play a bit with
expansion [not too complicated]

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 - mixed buffers

[Petr Ferdus]

On Wed, 27 Jun 2001, Hans Hagen wrote:
> rather tricky what you're doing. 
> 
> ow about 
> 
> \startbuffer[blabla]
> <p>more bla</p>
> \stopbuffer
> 
> \processXMLbuffer[blabla]
> 
> or 
> 
> \startXMLcode [name]
> .....
> \stopXMLcode
> 
> \getXMLcode[name]
> 
> however, the best way to get thing into headers and footers is to use the
> marking mechanism, where, in this case you need to play a bit with
> expansion [not too complicated]

both suggestions are working in the sence that they typeset XML
buffers/code (equally to previously observed behavior), so all pages
except last one gets one gets wrong footer.
Except plain XML text there is page dimension/orientation change at the
begin and the end of the XML buffer. Could that change the situation?

\startbuffer[mybuf]
<?context-command \setuppapersize[A5][A5]?>
<p>my beatiful text<p/>
.....
<?context-command \page \setuppapersize[A5, landscape][A5, landscape]?>
\stopbuffer

Thanks for hints.

Peter

Re: typeseting XML - mixed buffers

[Hans Hagen]

>both suggestions are working in the sence that they typeset XML
>buffers/code (equally to previously observed behavior), so all pages
>except last one gets one gets wrong footer.
>Except plain XML text there is page dimension/orientation change at the
>begin and the end of the XML buffer. Could that change the situation?

looks like a grouping problem, maybe you should explicitly do a \page
before the outer group

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 - mixed buffers

[Petr Ferdus]

Solution for this particular case was "wraping" regular buffer used in 
footer into contex-command directive:
\startbuffer[MyBufXML]
<?context-command \goto{Where to ...}[myref]
\stopbuffer

and including call for MyBufXML in "XML containting" buffer.
\startbuffer[MyXMLBuf]
....
<?context-command \setupfootertexts[{\getbuffer[MyFooterXML]}]?>
....
\stopbuffer

Suprisingly (and this leads me to believe, that expansiond/parsing engine
is somehow messed), after only one such inclusion all footers were strait
(even on pages, generated from other XML containing buffers, having no 
\setupfootertexts set, using just general footer setting valid in the
rest of document)

Hope this might help.

Peter

Re: typeseting XML - mixed buffers

[Hans Hagen]

At 12:43 PM 6/27/01 +0200, Petr Ferdus wrote:
>Solution for this particular case was "wraping" regular buffer used in 
>footer into contex-command directive:
>\startbuffer[MyBufXML]
><?context-command \goto{Where to ...}[myref]
>\stopbuffer
>
>and including call for MyBufXML in "XML containting" buffer.
>\startbuffer[MyXMLBuf]
>....
><?context-command \setupfootertexts[{\getbuffer[MyFooterXML]}]?>
>....
>\stopbuffer
>
>Suprisingly (and this leads me to believe, that expansiond/parsing engine
>is somehow messed), after only one such inclusion all footers were strait
>(even on pages, generated from other XML containing buffers, having no 
>\setupfootertexts set, using just general footer setting valid in the
>rest of document)

again this indictates that you process grouped. Actualy, there is no reason
to set footertexts each time, just set them up in the style. 

Do you really need the buffers? 

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 - mixed buffers

[Petr Ferdus]

On Wed, 27 Jun 2001, Hans Hagen wrote:
> again this indictates that you process grouped. Actualy, there is no reason
> to set footertexts each time, just set them up in the style. 
I would not touch footer text setting would it show up correctly.(It is
set once at the begining of document) I started to fiddle with it when I
could not have it right on certain pages (which happened to be generated
from buffers containing XML)

> Do you really need the buffers? 
Good question, next time I will do it differently, but in this particular
case i tried to minimize touching the source code.
>From the other side, it would be nice to know I can use them - if needed
(till I  know better solution).
BTW buffers with XML in it were quite sensitive to comments e.g.

\startbuffer[bla]%comment here should not hurt

actually hurts, if there is XML source in it(introduces some errors which
disapear if the comment is removed).

Peter

Re: typeseting XML - mixed buffers

[Hans Hagen]

At 09:41 AM 6/28/01 +0200, Petr Ferdus wrote:
>On Wed, 27 Jun 2001, Hans Hagen wrote:
>> again this indictates that you process grouped. Actualy, there is no reason
>> to set footertexts each time, just set them up in the style. 
>I would not touch footer text setting would it show up correctly.(It is
>set once at the begining of document) I started to fiddle with it when I
>could not have it right on certain pages (which happened to be generated
>from buffers containing XML)
>
>> Do you really need the buffers? 
>Good question, next time I will do it differently, but in this particular
>case i tried to minimize touching the source code.
>>From the other side, it would be nice to know I can use them - if needed
>(till I  know better solution).
>BTW buffers with XML in it were quite sensitive to comments e.g.
>
>\startbuffer[bla]%comment here should not hurt

since buffers set catcodes indeed the first line can have no comment 

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
-------------------------------------------------------------------------

pdf font resource support

[Petr Ferdus]

Hi,
capabilities of newly released Context are quite remarkable. (definitely 
speedwise and xml procesing related). Thanks.
At moment I would have one question. Context seems to  loose ability to
include 
pdf font resource in generated files. The problem might be in macro
\doincludepdffontresource where it never goes inside (at least in my
tests), 
and pdf file always ends up without resource table. What could be done
with it?

Thanks.

Peter

simple test file:
% output=pdftex interface=en
\useencoding[pfr]
\setupbodyfont[csr] 
\setupcolors[state=start]

\starttext
  \bf \v r \v R
  test \`z \'z \v z \bf test \sl test \bs quite funny \`z \v r \page
  test \`Z \'Z \v Z \bf test \sl test \bs quite funny \`Z \v R \page
  \showcharacters \page
  \showaccents
\stoptext

Re: pdf font resource support

[Hans Hagen]

At 12:26 PM 11/25/2001 +0100, you wrote:
>Hi,
>capabilities of newly released Context are quite remarkable. (definitely
>speedwise and xml procesing related). Thanks.
>At moment I would have one question. Context seems to  loose ability to
>include
>pdf font resource in generated files. The problem might be in macro
>\doincludepdffontresource where it never goes inside (at least in my
>tests),
>and pdf file always ends up without resource table. What could be done
>with it?

It looks like i didn't adapt it the updated font mechanism. I will fix it. 
Not that much a problem, but i want to keep it fast.

[first i have to move transparancy i.e. transparent colors into the kernel]

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

[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 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

[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 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

[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 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
-------------------------------------------------------------------------

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