[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Re: new Lynx SGML.c parser
From: |
Christopher R. Maden |
Subject: |
Re: LYNX-DEV Re: new Lynx SGML.c parser |
Date: |
Mon, 28 Apr 1997 15:19:12 GMT |
This is good stuff! I have a hard time reading the Lynx code - but if
I make guesses about how Lynx works, I get the answers I need.
[Foteos Macrides]
> I've been reading this thread, and am not sure I understand
> everything that's being said, or in turn, whether the participants
> know what's already there, and what the present limitations are on
> using any expanding SGML handling. My puzzlement is based on an
> earlier statement that the HTML.c stuff wouldn't need to be changed
> as well. It makes no difference how well you parse SGML
> declarations and marked sections if the *display engine* doesn't
> know what to do with markup other than that for the HTML it's been
> designed to handle.
My understanding *was* that the internal MIME types just triggered
handling; I didn't realize it was an implicit conversion. This is
still a useful metaphor, but:
> Back when it looked like Panarama might catch on, I added
> recognition of the MIME types text/sgml and text/x-sgml, and
> handling of SGML declarations and marked sections in
> SGML_character() via states which load their content into HTChunks,
> and then pass them to handle_foo() functions I added (e.g.,
> handle_doctype(), handle_marked(), handle_entity(), etc.). Those
> presently just send the chunk content to stderr if TRACE mode is on,
> free the chunk, and return to SGML_character(), but the intent was
> to add code in them for doing something worthwhile, when appropriate
> code, e.g., for expanding or modifying the entity tables in
> conjunction with Kurt's (err, I mean Santa Klaus') chartrans mods,
> or stuff that could interact with Rob's color/styles mods, or
> display engine enhancements in HTML.c, GridText.c and the LYfoo.c
> modules, also was added. If you don't have such code beyond that at
> present for dealing with the basic HTML via the display engine, what
> difference does it make if you've actually analyzed the additional
> SGML stuff? At least for now, we're making sure any additional SGML
> stuff received when the MIME type is text/sgml or text/x-sgml
> doesn't bleed through and garbage up the display. :) :) :)
Excellent. These look like a very good place to start. There are
really only a few other things I need to know.
I assume that the lines like
HTSetConversion("text/sgml", "www/present", HTMLPresent, 1.0, 0.0, 0.0, 0);
can be augmented for XML handling, using a totally new routine instead
of HTMLPresent. That new routine can borrow heavily from HTMLPresent.
Is this assumption warranted?
-Chris
--
Christopher R. Maden One Richmond Square
DynaText SIT Technical Support Providence, RI 02906 USA
Inso Corporation +1.401.421.9550 (voice)
Electronic Publishing Solutions +1.401.521.2030 (facsimile)
;
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.
;