- Inkscape Devel - Inkscape Mailman

Re: [cairo] New PDF backend snapshot (fwd)
by Bryce Harrington 21 Dec '04

21 Dec '04

---------- Forwarded message ---------- Date: Tue, 21 Dec 2004 15:41:47 -0500 From: Carl Worth <cworth@...573...> To: Kristian HÃ¸gsberg <krh@...618...> Cc: cairo@...278... Subject: Re: [cairo] New PDF backend snapshot --[[text/plain]] Kristian, Thanks so much for all your hard work on the PDF backend! I'm sorry I've been so slow to review it. I think this is good work, and I want it to land in CVS soon. I have a few comments, (most importantly with respect to the public API). On Wed, 15 Dec 2004 12:52:38 -0500, Kristian HÃ¸gsberg wrote: > I've pondering the cairo_document_t idea a bit and restructured the PDF > backend so that it's split into a cairo_pdf_document_t object and a > cairo_pdf_surface_t object. I believe this makes the code easier to > follow, but I'm no longer sure we need to expose a cairo_document_t in > the user API. If it's easier to have two objects in the backend, that is fine. > public API. 2) It will be a nice way to set metadata and other PDF > specific information for the document. Can't we just do that with cairo_pdf_surface functions? What advantage does the user get from having two different objects? So far, it seems the user just has to do more work before being able to use the PDF backend, (compared to the others). > +void > +cairo_set_target_pdf (cairo_t *cr, > + cairo_pdf_document_t *document); The notion behind the cairo_set_target family of functions is to allow the user to select a backend without having to create any new object. So the cairo_set_target_pdf function should accept the same arguments as cairo_pdf_surface_create. So, I think I would like to see the new public cairo_pdf API match the existing cairo_ps API exactly: cairo_surface_t * cairo_ps_surface_create (FILE *file, double width_inches, double height_inches, double x_pixels_per_inch, double y_pixels_per_inch); void cairo_set_target_pdf (cairo_t *cr, FILE *file, double width_inches, double height_inches, double x_pixels_per_inch, double y_pixels_per_inch); > There are two significant changes outside cairo_pdf_surface.c in this > patch: I've added the set_clip_trapezoids surface method which is > supposed to let cairo pass the absolute clipping path to the backends. (Kristian and I discussed this off-list and he has now proposed a new patch without the set_clip_trapezoids method. See: http://people.redhat.com/krh/cairo-pdf/cairo-pdf-4.patch ) > The other change is the addition of cairo_array_t implemented in > cario_array.c. This is an standard autogrowing array, doubling the > allocation size when it runs out of space. I was using chained lists > before in the PDF backend, but I converted those to arrays. I added the > array as a general data type, since cairo uses the same type of array in > other places and it might make sense to rewrite those places to use this > array type. Eliminating some code duplication seems like a good thing. But I don't like giving up type safety, and worse, I don't want to give up direct access of arrays using C [] notation. This kind of thing is always a tough call since C has no support for what we really want here. Regardless, if the code is to stay, then: > + if (old_size == 0) > + new_size = 1; > + else > + new_size = old_size * 2; > + > + while (new_size < required_size) > + new_size = old_size * 2; should be: new_size = new_size * 2; to eliminate the infinite loop. And these three functions: > +static cairo_status_t > +_cairo_pdf_surface_set_matrix (void *abstract_surface, > + cairo_matrix_t *matrix) > + > +static cairo_status_t > +_cairo_pdf_surface_set_filter (void *abstract_surface, > + cairo_filter_t filter) > + > +static cairo_status_t > +_cairo_pdf_surface_set_repeat (void *abstract_surface, > + int repeat) merit at least a comment stating they are unsupported. This isn't *too* big a deal as I want to eliminate these functions from the surface interface anyway, (they really only belong on patterns). Once the issues above are resolved I'd like to get this into CVS. I haven't actually played with the PDF output yet, but we can have fun playing with that after it lands in the tree. Thanks again. -Carl _______________________________________________ cairo mailing list cairo@...278... http://lists.freedesktop.org/mailman/listinfo/cairo

1 0

Re: [Inkscape-user] Textbox
by Bryce Harrington 21 Dec '04

21 Dec '04

On Tue, 21 Dec 2004, John Cliff wrote: > > On Thu, 16 Dec 2004 13:56:59 +0100, Imre Vida > > <Imre.Vida@...617...> wrote: > > > Do you plan to implement such a feature? > > > > Yes. In fact it already works, though there's no UI for it yet. See > > share/examples/flowsample.svg > > > > Theres no decent, complete UI, but to add the elements needed to put > text into shapes you can select them, right click and do 'add text to > shapes' to add the text itself you currently need to use the xml > editor. better than starting from scratch tho. What sort of UI does this need to have? Is this something that'll be easy to do, or will it need to be planned out? Bryce

2 1

Mozilla/Firefox SVG now has <image> tags
by Bob Jamison 21 Dec '04

21 Dec '04

This is so cool. The code for implementing the <image> tag in Mozilla SVG, which was previously a set of patches, apparently has made it into the mainline. Previously, the Mozilla guys were forced to use the <foreignObject> tag. Here is the SVG file w/images that I always use to test this stuff. Ignore the text alignment; obviously I need to convert it to curves. http://troi.hous.es3.titan.com/~rjamison/inkscape/files/ff_ccp_dump.png Bob

1 0

problem compiling from CVS, python-related
by Ben Crowell 21 Dec '04

21 Dec '04

Can anyone suggest how to fix/work around this problem compiling the latest CVS version? It seems to be related to python extensions. TIA! ======================================================================================= [snip] Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/fre etype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gt k-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/ usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/li b/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc++-2.0 -I/usr/lib/s igc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/i nclude/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/ lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 `p erl -MExtUtils::Embed -e ccopts` -I`python -c "import distutils.sysconfig ; prin t distutils.sysconfig.get_config_var('INCLUDEPY')"` -Wall -W -Wpointer-arith -Wc ast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT extension/script/extension_script_libscript_a-inkscape_perl_wrap.o -MD -MP -MF "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wrap. Tpo" -c -o extension/script/extension_script_libscript_a-inkscape_perl_wrap.o `t est -f 'extension/script/inkscape_perl_wrap.cpp' || echo './'`extension/script/i nkscape_perl_wrap.cpp; \ then mv -f "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wr ap.Tpo" "extension/script/.deps/extension_script_libscript_a-inkscape_perl_wrap. Po"; else rm -f "extension/script/.deps/extension_script_libscript_a-inkscape_pe rl_wrap.Tpo"; exit 1; fi Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/freetype2 -I/usr/include/fre etype2 -I/usr/X11R6/include -DPOTRACE=\"potrace\" -DXTHREADS -I/usr/include/gt k-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/ usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/li b/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/sigc++-2.0 -I/usr/lib/s igc++-2.0/include -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/usr/i nclude/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/gdkmm-2.4 -I/usr/ lib/gdkmm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/include/atkmm-1.6 `p erl -MExtUtils::Embed -e ccopts` -I`python -c "import distutils.sysconfig ; prin t distutils.sysconfig.get_config_var('INCLUDEPY')"` -Wall -W -Wpointer-arith -Wc ast-align -Wsign-compare -Woverloaded-virtual -Wswitch -Wno-unused-parameter -g -O2 -MT extension/script/extension_script_libscript_a-InkscapePython.o -MD -MP -MF "extension/script/.deps/extension_script_libscript_a-InkscapePython.Tpo" -c -o extension/script/extension_script_libscript_a-InkscapePython.o `test -f 'exte nsion/script/InkscapePython.cpp' || echo './'`extension/script/InkscapePython.cp p; \ then mv -f "extension/script/.deps/extension_script_libscript_a-InkscapePython.T po" "extension/script/.deps/extension_script_libscript_a-InkscapePython.Po"; els e rm -f "extension/script/.deps/extension_script_libscript_a-InkscapePython.Tpo" ; exit 1; fi Traceback (most recent call last): File "<string>", line 1, in ? ImportError: No module named distutils.sysconfig extension/script/InkscapePython.cpp:13:20: Python.h: No such file or directory extension/script/InkscapePython.cpp: In member function `virtual bool Inkscape::Extension::Script::InkscapePython::interpretScript(Glib::ustring&, Glib::ustring&, Glib::ustring&)': extension/script/InkscapePython.cpp:62: error: `Py_Initialize' undeclared (first use this function) extension/script/InkscapePython.cpp:62: error: (Each undeclared identifier is reported only once for each function it appears in.) extension/script/InkscapePython.cpp:67: error: `PyRun_SimpleString' undeclared (first use this function) make[2]: *** [extension/script/extension_script_libscript_a-InkscapePython.o] Er ror 1 make[2]: Leaving directory `/home/bcrowell/Documents/sw/inkscape/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/bcrowell/Documents/sw/inkscape' make: *** [all] Error 2 -

2 1

Re: File Chooser
by Bryce Harrington 21 Dec '04

21 Dec '04

On Tue, 21 Dec 2004, John Taber wrote: > For some reason I can subscribe to get the Inkscape mail list but my posts get > rejected so am sending this direct.... Can you forward us one of the rejection emails? Maybe we can figure out what's going wrong. > Yes, Gtk filechooser is a total DISASTER as seen by anyone in our office. In > fact it will probably surface more with Firefox as 10 million converts start > trying to download files. It even took me several weeks before I realized > the listbox on left is a bookmark list and it seems like now I just have to > go thru more keystrokes. So you have our vote to modify it to allow > filenames to be typed in. This type of Gtk weirdness really hurts Gtk > adoption. > > btw We now depend on Inkscape for our graphics work and thank all of you for > the great job you are doing on it - it is simply one of the most energetic > and best managed open source projects. How can we convince Fedora folks to > include it ? When Firefox hopefully soon supports SVG, Inkscape will be a > must and hot ticket. > John Cool, good to hear. I don't know how Fedora decides what to include, but perhaps you can send an email to them requesting it? An email to encourage Firefox's SVG efforts would probably be worthwhile too. Bryce

1 0

Multiple page documents in SVG
by Bryce Harrington 20 Dec '04

20 Dec '04

This question came up a couple times this past week. SVG 1.2 (which we don't yet support) provides a method for doing multiple paged documents: http://www.w3.org/TR/SVG12/multipage.html Example: <svg xmlns="http://www.w3.org/2000/svg" version="1.2"> <pageSet>  <page> <circle cx="100" cy="100" r="20" fill="blue"/> </page>  <page> <rect x="100" y="100" width="20" height="20" fill="red"/> </page> </pageSet> </svg> Bryce

4 3

-users -developers test please ignore
by vellum 20 Dec '04

20 Dec '04

1 0

test ignore
by vellum 20 Dec '04

20 Dec '04

1 0

RESEND: Bug with EPS-sizing upon import...
by Daniel 20 Dec '04

20 Dec '04

[Please cc: me on replies] Hi, I'm resending this after not hearing any responses to my first email over a period of two weeks... :) I'm using Inkscape 0.40 packaged for Debian unstable. If its an issue, I'm also using the AFPL-licensed version of ghostscript, version 8.14. I have noticed the following issue/bug, since I started using Inkscape, with version 0.39. Whenever I place EPS files into a new Inkscape document, they appear to be smaller (in pixel size or actual size, based upon bounding box) than they should be. For example, if I create both an EPS file and an SVG file produced by the command line version of potrace (which I was using with inkscape before it was included in the program as of version 0.40), using the exact same options and the exact same input file, they will import into Inkscape (both 0.39 and 0.40) with different sizes. The svg imported file will accurately reproduce the size of the EPS that I see when I use that EPS with other members of my tool chain (scribus, epstopdf, xpdf, acroread, etc.). Any ideas? Do you need anything else to quantify this? It appears very reproducible to me. Furthermore, when I export EPS from Inkscape (both 0.39 and 0.40), they appear (at least according to the "file" utility, to be regular postscript, rather than encapsulated postscript). I've tentatively tracked this down to be the lack of the full first-line of "%!PS-Adobe-3.0 EPSF-3.0" and instead only having "%!PS-Adobe-3.0". Ghostscript utilities, such as eps2eps, produce the full line, while inkscape produces the shorter version. Changing the latter to the former seemed to convince the Linux "file" utility that the file was now EPS. Any ideas on what's the right thing to do? Thanks again for a truly magnificent product. How it has wonderfully surpassed my expectations. Take care, Daniel PS I"ve given it to 6-8 of my less Linux-aware friends for use on their Windows boxen in the past few weeks. They are grateful.

3 2

Re: [Inkscape-devel] RESEND: Bug with EPS-sizing upon import...
by Daniel 20 Dec '04

20 Dec '04

Hi Bulia, Thanks for the reply... I'm guessing that you shouldn't need skencil to reproduce this bug and do a test EPS import, since I don't have it on my system and EPS imports work (I always assumed that you'd use ghostscript for EPS imports). Anyway, that bug looked familiar but the consensus was that something might be wrong due to an Adobe Illustrator issue. Mine however are EPS outputs produced only using Free Software tools (potrace from gimp-based input scan). If it really helps you, I could probably send you the inputs off-list, but I'd prefer to keep them private unless necessary. For the record, I can make it do this with any sample EPS file I gave it (comparing it to size in ghostview or through import into scribus). Thanks for the help. Let me know if there's anything else I can do. Any ideas about Postscript versus EPS recognition issue I mentioned also? Take care, Daniel > Whenever I place EPS files into a new Inkscape document, they appear > to be smaller (in pixel size or actual size, based upon bounding box) > than they should be. It seems to be this bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1027699&group_id=9… If you attach there your comments and the sample EPS and SVG files from potrace it would be very helpful. The bug seems to be easy to fix (apparently the px and pt units are confused somewhere, we had several bugs of this kind) but I can't fix it now because I don't have Skencil installed (afaik we can only import EPS via Skencil).

2 1