[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Updates to Import Filter framework
From:       John Califf <jcaliff () compuzone ! net>
Date:       2000-11-27 2:11:56
[Download RAW message or body]

Shaheed & Thomas:

Regarding all that you wrote below... We are talking about three
different things

1. using a krayon part in kword to handle krayon's native file format
similar to how kspread now does it.  Common code should take care of
that automatically if both apps use common code correctly, if you
provide a mechanism for inserting the part to begin with (menu items,
other gui, etc.).

2. dealing with imported MS documents that have images handled with the 
MS WMF that may contain an image, or many other things.  Krayon can
handle that but must have a format to deal with or at least a pointer to
raw image data - like device independent bitmap for Windows, I'd assume,
or gif, jpg, png, etc.  See point 3 on how to actually "show" the
image.  If you want krayon to handle the import/export of image data
within an MS Word document that can be done.  It's simply a matter of
using Qt to change the format to whatever you desire, so long as it is
not too exotic. Any file format normally used in kword or any Qt image
object krayon can provide for you. 

3. changing the default way kword handles images.  I like the way Kword
now does it - in a simple way.  Use Qt - QImage or QPixmap, keeping the
image data taken from a file in a qt format for kword to show.  The
point is that images are COMMON in kword, and they are an entity. 
Krayon should not be needed to show an image unless editing is required,
if an image can be shown in a simple way. That is why I suggested a
pass-thru filter which let's krayon handle the image data just by
returning it back, but when the user chooses to edit that image by
double clicking then krayon imports it into its native format and
handles it with an embedded part - which can be created on the fly.    

Please understand that the .kis file format is a complicated one with
channels and layers that aren't useful unless you want to actually edit
the image.  Like Gimp. Everything would have to be crammed into one
layer to start.  Nobody uses .xcf for final output in documents.  That's
mostly useful to artists in working on art and the final result is
almost always saved as jpg, png, etc.

Whatever you want can be done. Just give me your specs - or later, code
which I have to handle or repsond to.  We certainly don't want to make
the same mistake MS made with compound documents - Shaheed - tell Thomas
about that.

John


Shaheed Haque wrote:
 
> 
> Oh I never had a problem with your suggestion, intended for me or not! I'd
> love to see it done, or have the chance to do it myself :-).
> 
> >2.  krayon and kword.  As you may already know, krayon's format is .kis,
> >something like Gimp's .xcf format.  It would be extremely rare to use
> >that format directly in a kword document, or even in killustrator.  What
> >would normally happen is that someone would have a common image format
> >like a jpg or png in kword for a picture, either inserted directly in a
> >text frame or in a special image frame.
> 
> [snip]
> 
> The trouble is not with us, it is the Microsoft code. For the following, I
> want to distinguish "images" (e.g. bitmaps, jpgs) from "vector graphics",
> and from "drawings" (images or vector graphics).
> 
> Here is the difficulty. Although MSWord can theoretically store images
> directly, it rarely seems to do so. Instead, it typically wraps images
> inside a vector format (e.g. MSOffice drawing file format, or WMF). The same
> probably applies to Excel etc.
> 
> The vector wrapper used seems to vary depending on the exact command used to
> include the image (insert picture->clipart, insert picture->from file,
> insert object->bitmap, insert object->blah).
> 
> We obviously don't want to repeat this mistake, and so, when we agreed in
> http://lists.kde.org/?l=koffice&m=97355383400131&w=2 to distinguish only
> between images and vector grpahics, I took this to mean that images should
> *always* be handled by krayon.
> 
> Now, for vector graphics generally, I am writing import filters for
> killustrator, and will use the cross-filter embedding to invoke the right
> filter (using the so filter query stuff so it will auto-adapt as new filters
> or applications are developed).
> 
> This will also handle all thes common vector-wrapped images, since it is all
> based on mimeTypes. So, the user's experience of an image which has been
> vector-wrapped by MSWord/Excel/... will be an embedded killustrator part.
> 
> It is therefore logical to treat the case of images (without vector
> wrappers) as simply an embedded krayon part.
> 
> Thus, even the complex case (e.g. MSOffice Drawing containing a WMF
> containing an image) is simply nested killustrator and krayon parts (as per
> http://lists.kde.org/?l=koffice-devel&m=97476394815102&w=2).
> 
> >  Kword internally stores these
> >as QImages, I believe, so that reference to the orginal image file is no
> >longer needed for the image to show up when loading a .kwd doc with
> >pictures in it.  Krayon can fairly easily load a QImage, IF the user
> >wants to edit that image.  Unless the user wants to edit the image,
> >krayon would not need to handle the image in KWord.  That would be
> >wasteful overhead.
> 
> For me, the kpart overhead is the main unknown (but see below). My current
> assumption for the kpart stuff is that since it is no more than a function
> call or two away, it should not be too cumbersome.
> 
> >Currently there is no way I know of to edit an image inside Kword,
> >either internally with an embedded koffice part, or externally by "open
> >with" an image editor of the user's choice.  When you right click on an
> >image in a picture frame in kword, there should be an "open with" option
> >for editing, perhaps in the "properties" dialog you now get when right
> >clicking.
> 
> That's no different from the embedded UI, right. Just double-click on the
> frame to open it.
> 
> >In some cases one may want to directly embed a .kis (krayon's native
> >format) image in a kword document.  In that case, normal koChild
> >processing should handle it, similar to the way you can now embed a
> >kspread part in a kword document.  However, again, there is no mechanism
> >for doing this.
> 
> [snip]
> 
> Note that since this is all from the filter, I don't need a UI to do the
> insert! Eventually, though, this would be good.
> 
> >Ideally, what is needed is a pass-through filter for all image types in
> >krayon so that kword just shows the image as usual unless the user wants
> >to edit it, passing through a krayon handler which does nothing.
> >However, when the user decides to edit, then the image is loaded into
> >krayon, as a part, exporting it into native format if necessary for an
> >image to be edited or adjusted before or after inserting it into kword.
> >You know, when you first insert a new image into Kword it has to come
> >from a file. This would have low overhead but still allow for
> >embedding.  Krayon can already import and export all the commmon image
> >types kword uses, and can handle QImages (or QPixmaps) that may already
> >be in a kword document.
> 
> This is an interesting idea. Is the overhead you are worried about something
> to do with the memory or CPU used by krayon, as opposed to the kpart? If so,
> I see your concern. If it becomes a problem, then you are right, some scheme
> like this may be required. Since I would expect killustrator to also handle
> images via krayon in the long run, it could benefit from this too.
> 
> Let us get the architecture right...we can optimise later. I hope that all
> makes sense!
> 
> Shaheed
> _____________________________________________________________________________________
> Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com
> 
> _______________________________________________
> Koffice-devel mailing list
> Koffice-devel@master.kde.org
> http://master.kde.org/mailman/listinfo/koffice-devel
_______________________________________________
Koffice-devel mailing list
Koffice-devel@master.kde.org
http://master.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]