RE: [xml] Problems using xmlIOParseDTD() with given encoding

["Keim, Markus" <markus_keim ordat com>]

> -----Original Message-----
> From: Daniel Veillard [mailto:veillard redhat com]
> Sent: Tuesday, November 04, 2003 4:50 PM
> To: Keim, Markus
> Cc: libxml2 mailing List (E-Mail)
> Subject: Re: [xml] Problems using xmlIOParseDTD() with given encoding

<snip />
 
> > So, for what i currently see it's
> > - not possible to use xmlIOParseDTD() with a given
> >   encoding in recent versions of libxml2
> > - it's possible in prior versions, but the encoding won't
> >   be took into account
> >
> > I'm tackling things wrong or is there an actual problem
> > in libxml2?
> > And if so, how could it be solved (i don't think that the
> > check for (ctxt->input != NULL) in xmlSwitchToEncoding()
> > could be generally dropped)?
>
>   This can't be dropped, can you bugzilla this ?
> apparently this need fixing, probably simply by maling sure the input
> is actually set-up ...
>
>     thanks,

OK, BTDT.
It seems to be some kind of "bootstrap" problem.
The problem arises in xmlNewIOInputStream() that is
used to build a new "xmlParserInputPtr" from the
given "xmlParserInputBufferPtr".
A subsequent call of xmlPushInput() switches the
input of the new context to that pointer, now we could
call xmlSwitchEncoding() riskless, but it's too late... =|
Maybe there's a similar call to xmlNewIOInputStream()
that builds a new "xmlParserInputPtr" w/o switching the
encoding, if so, we could call xmlSwitchEncoding() in
xmlNewIOInputStream() after xmlPushInput().
If not (and my approach is right), i'd be glad to provide
a patch, it should be a trivial derivation from
xmlNewIOInputStream() (which than could be implemented
using the new call).

Ciao, Markus

 
> Daniel
>
> -- 
> Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
> veillard redhat com  | libxml GNOME XML XSLT toolkit  
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/