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

List:       koffice-devel
Subject:    Re: The road goes ever on
From:       Dirk_Schönberger <dirk.schoenberger () sz-online ! de>
Date:       2002-10-30 8:31:57
[Download RAW message or body]

> |  The idea behind what you did is using EPS as some kind of "container"
for
> |  the actual image / bitmap data. This is possible, but it should only
used
> |  for outputting to a real Postscript printer. You don't convert the
image
> |  data to vector data, but instead convert the image data from its
> | compressed form as PNG to an uncompressed form which is uncompressed
> | form useable by a printer.

> You haven't mentioned that you want to convert image to *vector format*!

Sorry I think I missed your intended purpose for using EPS files. If you
want to convert arbitrary images into EPS containing the image data, for
later inclusion into LaTex, your proposed tools seem to be ok.
My prefered work is around real vector images, so I tried to show you my
prefered tools ;)

> Yes, there is an Open-Source autotrace, which also can be used by
> ImageMagick,
> BTW (if it is installed).
> But do you really wnat to *autotrace* PNG or JPEG, during export to
Latex?..

Again, I misunderstood you. For image data you don't need no autotrace. But
do you really need EPS? Aren't there other ways to include image / bitmapped
data into Latex?

> You take your image, and convert  *each pixel* to rectangle, than position
> each pixel one after another.
> Rectangle would have default RGB value of that pixle as 'fill', and no
border
> (stroke:none).
> For the reference image which I used this would produce:
> 160x160=25600 rectangles.
> It would be interesting to see png2svg utility doing this job.
> (which would greatly complement Karbon14' set of tool, IMO)
> I guess 'rect' primitive is ok for this task, no need to use 'path'
I want to use vector data not out of fun, but because to be able to later
change the data (recolor, change the resulting paths). Your proposed process
would create not especially useable vector data, not to speak from the
performance hit while rendering :)

> Such approach even would allow scaling for those pseudo-vector images.
> If you use scaling factor of 3X, you need just to replace solid fill with
> linear gradient, and you will get smoothing/scaling working for raster
> imeges!
> // high-end PS interpreter does scaling of images exactly in such way,
BTW.
I know, but ther exist special image render operators, so you can send you
image data directly to the printer, instead of converting them into render
primitives first.
I think, this way is also the way tools like pnmtops works. The "uncompress"
the original data (or rather, another filter does this, pnm is
uncompressed), and write PS code which transfers the image data and an
rendering operator to the printer.

> |  What do you want to achieve? From what I understand, SVG is more suited
to
> |  "clip art", i.e. one page, or a small area thereof, similar to EPS.
Real
> |  Postscript files mostly contain multiple pages.

> Com'on, SVG is XML-based.
> You always can have a wrapper around several SVG images, in XML format.
> The easiets way to achieve this is to use XHTML+CSS, or XML+CSS, with
> paged media (@media page)
I agree, that this would be possible. It is however, no "genuine" SVG, so
you still have to find an application / device which can render your file.
Last I know is that there is not integrated xhtml or svg rendering
capability in your common printer.

For displaying of multipage documents on screen you may also consider PDF.

Regard
Dirk















_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]