Subject: Re: A Proposal (why we should have setBold(true))
From: sam th (sam@bur-jud-118-039.rh.uchicago.edu)
Date: Thu Jun 01 2000 - 00:18:04 CDT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 31 May 2000, Paul Rohr wrote:
> At 11:24 PM 5/31/00 -0500, sam th wrote:
> >Well, I had never planned to implement HTML, as opposed to XHTML. I have
> >no desire to write that parser (and it would belong in the importer).
>
> Wise move. ;-)
>
> >But
> >the problem is that with your first example, the importer has to keep
> >track of the state of the formatting at any given point, which is
> >information that is avalible in the PT.
>
> Oh. I didn't realize you were trying to avoid keeping track of the current
> state. That's easy to do, especially for a cleanly-nested format. Just
> push and pop a stack based on the nesting depth -- all the information you
> need can be read off by just walking the stack. Caches don't get much
> simpler than that.
>
This would work nicely for properties that are binary (like bold) but gets
more complicated for the <font> tag, say. And then lots worse if you try
to include CSS properties (which I am *not* planning on doing at the
moment).
> >This is why I think that a
> >controller class, as suggested by Jeff among others, is the best way to
> >handle this.
>
> I suspect the controller class (to get access to the IP, right?) is a red
> herring. See below.
>
> >Now, if I had an insertion point while I was doing the importing, the PT
> >would be much easier to use (I could just use the sort of code FV_View
> >uses). I could then make changes to formatting, instead of just appending
> >further formatting. But the view maintains its own insertion point, not
> >the PT.
>
> Now I get it. Even if you really don't want to keep track of the current
> format state yourself, you still don't need an insertion point. Importers,
> by definition, are always appending to the end of the document. All you
> need is the format at the end of the document.
>
> Sounds like at most one API change, if that.
I think you're right about this. If I knew what the format was at the
current point, then my code would be fairly similar to _toggleSpan() in
ap_EditMethods. However, getting the current format is easy - if you have
an insertion point. Are you suggesting that I keep track of the insertion
point in the importer?
>
> >And lest you think that this is unique to XHTML, you should look at a
> >KWord document sometime. Importing that would take yet more heavy lifting
> >(which would be easier with a controller).
>
> Huh? That can't be right. Is KWord's format really harder to import than
> Word's? Ick.
KDE uses some really gruesome XML as their file format. It's certainly
easier to interpert than a binary Word document, but probably harder than
what wv feeds us (it's nice that Caolan did all our work for us).
Well, you've provided some good suggestions, so that it seems like radical
surgery may not be neccessary for this importer. I still think the current
implemntation could use improvement, but that could wait for when there's
nothing else to do. (Ha).
Thanks
sam th
sam@uchicago.edu
http://sam.rh.uchicago.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5NfINt+kM0Mq9M/wRAnUMAJ4thecSf2Hk+FYW26tNlM2+apb3hQCfc6Bi
wGNi3NWmH8lpF/5GQBqyfR8=
=aT7G
-----END PGP SIGNATURE-----
This archive was generated by hypermail 2b25 : Thu Jun 01 2000 - 00:18:03 CDT