Hi Martin,
> > *) Not bloating the file's size. Base64 will
> expand
> > the objects' size significantly.
> >
>
> We could achieve the same effect by emitting gzipped
> .abw by default.
No, it wouldn't. What that would achieve is a
compression of the bloated base64 version. That is not
the same as compressing the original version of the
data. The base64 version would still be significantly
larger.
> My in-experience shows here. To me, having a blob of
> base-64 right in an
> XML document makes it much easier to understand the
> rest of the document.
> I'm not sure how splitting an XML document over
> several files helps me as
> the developer of AbiWord.
Just like having font files embedded in PS and PDF
files helps preserve the readability...
Anything not germane to the document's style or
structure hurts readability, thus impairing
comprehensibility. Having a 300-line long sequence of
base64 compressed text at best doesn't hurt
readability, if it's hidden all the way at the bottom
of the file. But my mind can't parse base64'd PNGs. I
need libpng plus a monitor to do that. The genuinely
useful bit of information is contained in the:
<d dataid="something">
tag. Anything else is just implementation details best
handled by libpng or similar and gets in the way of
real human understanding.
> > especially wrt potentially large embedded objects
> such
> > as images, XL spreadsheets, etc. Abi has problems
> with
> > big data now (especially wrt RAM usage), and
> you've
> > suggested "more of the same", which seems
> > less-than-ideal.
>
> The issues with RAM usage are almost independent of
> the PT. The images and
> in the PT are stored as PNG. When displayed in
> AbiWord they're bitmaps.
Not entirely. The design of AbiWord's PT is such that
it can't load and unload things on-demand. This has a
second-hand effect of causing things like a complete
copy of the layout, runs, images, etc. to be kept
in-memory for use by the display and layout engine.
This is where the larger memory issue lies, and I'm
sure that you'd agree. However, it's a symptom of
another problem, and not a problem in itself.
> > If it were possible to lazy-load
> > these objects, we'd might be able to load them
> > on-demand, and passivate the objects out of memory
> > when they're not in use.
> >
>
> I'm not sure this is possible within the framework
> of AbiWord being a
> cross platform application. We really need the full
> data stored directly
> in document.
That's laughable, especially in the context of a
cross-platform plugin embedding thread. You're telling
me that fseek'ing to an offset within a file on-demand
and then fread'ing isn't portable. Or that creating a
temporary cache of things, like say web browsers do,
isn't cross-platform.
> We can make a PNG snapshot of any document that can
> display itself in our
> graphics class already. I will write a XP PNG
> snapshotter as part of the
> base class.
>
> I think the statement is overly pessimistic of the
> possibilities of SVG
> snapshots.
> You have already written an SVG backend for
> gnome-print. We can simply ask
> any programs that supports gnome-print to print
> itself to SVG and use
> that.
You're suggesting that things will want to draw with
our graphics class, gnome print or something
equivalent. That's not an assumption I'd make,
especially in light of where I think the real use-case
benefits are for our users...
> I'm working on getting the MathML code into the
> plugin framework now. I'm
> mostly a bottom-up developer and I'm discovering
> issues with the API as I
> do the work.
>
> My feeling is that we should evolve our API as we
> gain experience. If
> there are specific short comings you can see with
> it please let me know.
No doubt things can change once we gain experience,
though such a position does not duly appreciate
code/design inertia.
If the goal is to have a MathML or SVG plugin draw
using our graphics class, then your solution is great.
The design starts breaking down dramatically once you
get past that hurdle, though. And, in my opinion, many
of the interesting cases from the POV of our users
will be on the other side of that hurdle.
> You know I hold your opinions in the highest regard.
And I yours.
Best regards,
Dom
__________________________________
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
Received on Fri Jan 14 02:19:28 2005
This archive was generated by hypermail 2.1.8 : Fri Jan 14 2005 - 02:19:28 CET