From koffice-devel Wed Oct 30 08:31:57 2002 From: =?utf-8?Q?Dirk_Sch=C3=B6nberger?= Date: Wed, 30 Oct 2002 08:31:57 +0000 To: koffice-devel Subject: Re: The road goes ever on X-MARC-Message: https://marc.info/?l=koffice-devel&m=103596782511142 > | 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