Re: Problems mapping Xml into ConTeXt

[Michael Wigston <Michael.Wigston@asic.gov.au>]

[-- Attachment #1.1: Type: text/plain, Size: 3320 bytes --]

> Michael Wigston wrote:
> >
> > Hans Hagen wrote:
> > > Michael Wigston wrote:
> > > > 1.  This def of <u> does nothing ...
> > > > \defineXMLgrouped [u] \underbar
> > > >
> > > \defineXMLargument[u]{\underbar}
> > >
> > > underbar is not a font switch but a macro that takes an argument
> >
> > Hans,
> >
> > Thanks, that works fine with \underbar, as well as \underbars, 
> > \overstrike, \overstrikes, \low, \high and \lohi.
> >
> > You mentioned that \underbar (and presumably the others I mentioned 
> > above) are macros taking arguments e.g. \acommand{...}. However 
> > presumably something like \midaligned{...}  is also a macro requiring 
> > an argument, but this works as a \defineXMLgrouped and as a 
> > \defineXMLargument - why does it  work with both?
> the macro ones do manipulate their argument, for instance, underbar is 
> not a font charateristic or color switch or so i.e. not a real 
> attribute; esp using setups will make your style look better (look into 
> x-fo for instance, forget about the dirty tricks there, but it's pretty 
> clean; mapping values and so save many macro definitions
> >
> > The manual "XML in ConTeXt" very briefly sketched over these XML 
> > commands and I can see great potential to use them directly on XML to 
> > generate ConTeXt for PDF rather than the XSLT/XSL-FO route which seems 

> > to be gaining momentum in much of the industry. I don't suppose there 
> > is another more detailed document which elaborates on the XML 
> > commands, and how you may determine which of these is most appropriate 

> > for what kind of ConTeXt command mapping? 
> you can take a look into the x-* files which show quite some mappings; 
> indeed direct mapping is often more convenient than transformations; 
> future versions of context will also offer more manipulation 
possibilities
> >
> >
> > Also at the moment a non-mapped element seems to automatically type 
> > out its contents as straight text - is there a way to override this 
> > behaviour and specify this as an error? (This is rather like the Ruby 
> > duck-typing approach - if an XML element is mapped, process it, else 
> > it is an error). 
> \startXMLignore
> \stopXMLignore 
> 
> in xtag-pre you can see: 
> 
> \defineXMLenvironment [\s!default] \defaultXMLelement \defaultXMLelement
> \defineXMLsingular    [\s!default] \defaultXMLelement
> 
> % \def\defaultXMLelement
> %   {\iftraceXMLelements[\currentXMLfullidentifier]\fi}
> 
> \def\defaultXMLelement
>   {\iftraceXMLelements{\infofont<\currentXMLfullidentifier>}\fi}
> 
> %D We can use the default handler to implement automatic
> %D element hiding. Beware: this overloads the tracer.
> 
> \def\startXMLignore{\dododefineXMLignore \s!default}
> \def\stopXMLignore {\dododefineXMLprocess\s!default}
> 
> so you can play with the default handlers 
> 

Thanks, looks like I'll have to do some digging in the x-* files ...

Regards,


NOTICE
This e-mail and any attachments are intended for the addressee(s) only and may be confidential.  They may contain legally privileged or copyright material.  You should not read, copy, use or disclose them without authorisation.  If you are not the intended recipient please contact the sender as soon as possible by return e-mail and then please delete both messages.  This notice should not be removed.  

[-- Attachment #1.2: Type: text/html, Size: 4305 bytes --]

[-- Attachment #2: Type: text/plain, Size: 139 bytes --]

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context