lynx-dev
[Top][All Lists]
Advanced

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]