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

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


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 Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]