Re: RFC: Pushing Math support into plugins

On Wed, 2004-07-07 at 16:17, Marc Maurer wrote:
> I agree, but it is currently not possible. Our layout engine does not
> support layouting arbitrairy (and possible unknown) objects.
>

True, but I get the feeling some folks (not just you) might be
overestimating just how far from being able to we really are. A lot of
the format and pt code (regarding fields, frames, images, etc) was
designed or redesigned with just this in mind (not doing it, but putting
small pieces in place along the way and making the existing code as
ready as possible for when it is done, which looks to be soon now).

(restating from irc for list) It isn't trivial, but I think we agree
that it isn't premature either, we're pretty much ready to make the
final preliminary discussions (like this) and finally dive into this
(outside of mainline of course for now).

Martin has the best grasp on those pieces code, since most of it was
written by him (for examples of stuff that's just begging to be
abstracted to our hypothetical object, see pf_Frag_Object and it's
relatives, or see the classes from which your friendly neighbourhood
frame (textbox) is derived). You can even iirc see bug reports (re
images, for example) where mention is made of fixes done by utilizing
the aforementioned classes the way text boxes do.

(look at abi_object.txt, the visual and piece representation of our
hypothetical object abstraction is just barely more than an abstraction
of a text box. Add a couple attributes here or there for which textbox
would use defaults, wind in a couple ui hooks...)
have you noticed that the proposed visual rep for an unsupported object
(without a specified alternative rep which was also discussed on irc) is
nothing more than a textbox with a grey background and missing caret?
(-:

(I know, it's also more work than I make it sound, just trying to give
pointers to how I might focus myself)

Anyway, I'm most interested, now that textboxes are in place, in hearing
what martin has to say about the useful code that IS already in place
(if needing more abstraction work, just how much, for example?)

> http://130.89.227.64/uwog/abi_object.txt
>

My main point I've already given, that a lot of the mentioned
hypothetical classes aren't all that hypothetical. I think a detailed
survey of fmt/ and pt/ code that isn't use-specific (like the
pf_Frag_Object code but not so much the *_Bookmark code which uses it)
would be a potentially good approach. And no, such I survey needn't be
formal, nor all at once.

Only other point would be to plan on allowing alternative
representations in addition to falling back on the grey box (for
example, a jpg/png alternative rep of an svg could be useful for
displaying on a box without the svg plugin).
But that's just a detail for later, worrying about it now would be
putting the cart before the horse.

I'm glad we (well, not me, the people who end up coding this) are
finally getting around to this. I think the timing is right, too. We
have table and frame and image objects, mathml objects too, in its
branch. What better opportunity to make object objects (-:

(we also have field objects, marker objects, noteref objects... d= )

Regards
-MG, nightmarishly verbose as always

Oh, P.S.: Martin, as hard as it is, documentation of your existing code
(frag_object for example again) would make it a lot easier to work on
this, and posts like this would be much less speculation, much more
exact. Uwog and anyone else, documentation of the new arbitrary object
code is _necessary_ for it to be really effective, because that lowers
the bar greatly for people who want to implement new features (like math
or whatever) this way. As discussed on irc, not every project
maintainer is gonna overhaul his entire codebase for us, like luca's
doing. What wasn't discussed on irc was how much more useful this
object architecture is when people besides those who wrote it (who could
just as easily hardwire new features/deps) can read up and use it.

yay, world's longest P.S., w00t.
Received on Thu Jul 8 02:30:55 2004