March 2005 - Inkscape Devel - Inkscape Mailman

Please help fixing i18n bug
by Samphan Raruenrom 11 Mar '05

11 Mar '05

Please help fixing the bug 1093864 http://sourceforge.net/tracker/index.php?func=detail&aid=1093864&group_id=9… It renders Inkscape almost useless for Thai (and other CTL languages). I guess any nonspacing combining character, no matter what language it is, shouldn't work too. Please tell me if there're anything I can help (e.g. test cases, I can't attach the file to the issue). Thanks. -- _/|\_ Samphan Raruenrom.

2 5

Duplicating libcroco code in Inkscape tree
by Peter Moulder 11 Mar '05

11 Mar '05

I am working on supporting non-inline CSS stylesheets, by using libcroco (a C library for CSS parsing and determining what CSS properties apply to a given element). Not quite: libcroco 0.6 (the most recent released version) isn't really suitable for Inkscape's use for finding what properties apply to a given element: it requires a libxml in-memory representation of the document tree rather than allowing use of our preferred Inkscape::XML::Node. (See near end of http://www.inkscape.org/cgi-bin/wiki.pl?CSS_Support for more details.) I have prepared some modifications to libcroco to make this more suitable for us, and I've gradually been feeding patches to the libcroco maintainer, but that will take some time for all the changes just to reach CVS, let alone be released as libcroco 0.7, let alone be available on a reasonable number of our users' systems. There are two main ways of addressing this that I'm considering: i) Put our own version of the rule selection code (cr-sel-eng.{c,h}) into Inkscape, and make it play nice with an installed (external) copy of libcroco 0.6. ii) Put all of libcroco into the Inkscape source tree. For (i), there are two aspects of "playing nicely with installed libcroco": - Getting `#include "cr-foo.h"' to find cr-foo.h (usually referenced from user apps as `#include <libcroco/cr-foo.h>'). The simplest approach is to change all `#include "cr-foo.h"' to `#include <libcroco/cr-foo.h>'. This is my preferred approach at the moment. It's tempting to try instead to get `-I/usr/include/libcroco-0.6/libcroco' (or whatever the path on the user's system) into our INCLUDES variable. This approach would be pleasing in its simplicity, and would also slightly reduce work in merging changes back into upstream libcroco. However, given that the exact path varies from system to system, the best I can think of involves adding to configure.ac something like ink_cr_incl=`pkg-config --cflags libcroco-0.6 | sed 's, .*,/libcroco ,'` INCLUDES="$INCLUDES $ink_cr_incl" (while retaining libcroco-0.6 in a PKG_CHECK_MODULES call, which would take care of LDFLAGS and error handling). Not too big a deal, but then neither is the #include-changing alternative. - Avoiding linkage errors from having cr-sel-eng symbols both in Inkscape's internal libraries and also in installed libcroco. Is there some linker options to avoid this? Otherwise, the alternatives are either to #define all the external symbols of our own cr-sel-eng to something else, or to convert cr-sel-eng.c to C++, which I believe should give different linker symbols (mangled); we could wrap in a namespace{} too if we want. My local copy uses the convert-to-C++ approach. It involved adding explicit casts in a dozen or so places (no implicit cast from void* in C++, no treating enums as ints). Approach (ii) has at least the following advantages & disadvantages: Advantages: - All libcroco source files can stay in C and can retain their existing #include text. - It guarantees us that libcroco is available. Otherwise we must choose between either: - Requiring libcroco (and bundling on some platforms with poor package management -- can't they all just use Debian? ;-) ); or - Using `#ifdef WITH_LIBCROCO' in the source code, and accepting that not all builds of 0.42 (or whatever) will be able to read SVG files using non-inline style. Disadvantages: - Makes Inkscape source tree about 1MB bigger, and increases Inkscape's memory usage at runtime. - Any bug fixes to libcroco would have to wait until at least one release of Inkscape before being fixed. This is most of concern if the bug fix is security-related. Licensing doesn't seem to be a problem: libcroco appears to be LGPL. I haven't yet checked with the libcroco maintainer for his comments; I'll bcc him. Can people add to this list of advantages & disadvantes, or suggest alternatives, or give other relevant information? pjrm.

7 18

icon issues
by bulia byak 11 Mar '05

11 Mar '05

Jon, a couple small icon-related things: 1 when double clicking a guide to open guide dialog, i get ** (inkscape:24066): WARNING **: failed to load icon 'guide_dialog' 2 launch, ctrl+n to open a new window, ctrl+q to quit: (inkscape:24082): Gtk-CRITICAL **: gtk_size_group_remove_widget: assertion `GTK_IS_SIZE_GROUP (size_group)' failed

2 3

icon preview?
by bulia byak 10 Mar '05

10 Mar '05

Jon, what is this new icon preview dialog? Is it temporary?

4 6

text recommended reading: W3C charmod
by unknown＠example.com 10 Mar '05

10 Mar '05

Recommended reading for anyone here working on text stuff: http://www.w3.org/TR/charmod/ -mental

1 0

New text layout code
by Richard Hughes 10 Mar '05

10 Mar '05

I've just committed the first part of my text layout rewrite. The patch got a little excessively large so there's bound to be breakage somewhere (probably a lot of places). If you assign any bug that looks to be my fault to me (cyreve) that would be helpful. It's a little sparse at the moment, but I'm hoping to ramp up the features fairly quickly now I've got a decent base to work on. Known regressions: 1) Things go wrong if you delete a line break and then add one in the same place. I know exactly what I need to fix. 2) Linespacing was implemented as a custom attribute on the <tspan> fields. I want to move this into the css before I enable it (it's neater if everything is in SPStyle) but will, of course, retain backward compatibility with old files. 3) Likewise justification on <flowtext> (although I don't imagine anybody's seriously using this currently). 4) flowtext editing on the canvas didn't work very well before, and it still doesn't work very well. 5) I think vertical text is probably broken. It's been a while since I tried it. The old implementation was actually wrong according to the css spec, because the latin glyphs should have been rotated 90 degrees by default. New stuff that works now: 1) share/examples/flowsample.svg renders the rtl portions correctly 2) Up/down movement in text goes straight up and down, rather than going to the same character index in the line above. Also, it doesn't jump from one side of the gap in flowsample.svg to the other. It still drifts a bit over repeated up/down because I've left some compatibility layers in. 3) Insertion and deletion of text with styles should keep the XML tree a bit cleaner than before. 4) Um...I made the cursor go italic when you're over italic text (well I thought it was cool). This doesn't work for Bitstream Vera because oddly enough they didn't specify the angle of the italic text in the font file. New stuff that will work in the short to medium term: 1) Editing <flowtext> 2) Line spacing, full justification and whatever other 'easy' css properties I can find 3) Text selection, maybe a text toolbar too if I can persuade Bulia to write it for me :-) New stuff that will work eventually: 1) Moderately complete css3 Text functionality 2) Anything else that I dream up along the way That's it I think. Now I just wait for the bug reports to fly in. Richard.

3 5

printing
by herve couvelard 10 Mar '05

10 Mar '05

Hello, just une question, when it come to printing (wokrs fine). a ps files from inkscape show : <snip> %!PS-Adobe-2.0 %%BoundingBox: 0 0 596 842 %%HiResBoundingBox: 0 0 595.276 841.89 0 841.89 translate 0.8 -0.8 scale gsave [1 0 0 1 0 0] concat 0 0 0 setrgbcolor <==== taht is real black there newpath 47.4377 88.6988 moveto 47.4377 113.095 lineto 70.4789 113.095 lineto 70.4789 88.6988 lineto 47.4377 88.6988 lineto closepath </snip> but the printer (HP desjet 1220C - inkjet printer - cups hpijs driver) use black+color cartridges where/how can track that down to make her print only with black cartridge for black text ? Thanks in advance hervé

1 0

Re: [Sodipodi-list] Re: I can't admin the project after all
by Jon Phillips 10 Mar '05

10 Mar '05

On Wed, 2005-03-09 at 21:19 -0500, Pat Suwalski wrote: > Michael Schumacher wrote: > > Is there anything in Sodipodi that's not in Inkscape? Probably nothing > > except the more modular interface, and this is currently being worked on (in > > the direction of GIMP-style tabbed docks, AFAIK). > > There is one feature that was added shortly after the fork, and that is > applying transformations. So, if a point drawn at [0,0] was moved x+5 > and y+3, then applying would make its actual coordinated [5,3]. I can't > seem to find equivalent simplification commands in Inkscape, and I > certainly use them as it makes things like rotations and such far more > compatible. > I've forwarded this to the Inkscape list, as it has been talked about before. If it is useful, then it should get a look at...especially, if you all would like to see in Inkscape. Jon > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Sodipodi-list mailing list > Sodipodi-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sodipodi-list > -- Jon Phillips USA PH 510.499.0894 jon@...235... http://www.rejon.org Inkscape (http://inkscape.org) Open Clip Art Library (www.openclipart.org) CVS Book (http://cvsbook.ucsd.edu) Scale Journal (http://scale.ucsd.edu)

1 0

No more dialogs!!!
by Jon A. Cruz 09 Mar '05

09 Mar '05

I just wanted to say... We should not be coding dialogs any more. Instead we need to keep in mind breaking things down and making them reusable. One thing would be to avoid subclassing Gtk::Dialog. Instead we should have things more generic, and come up with a generic class based on Gtk::Container. These composit widgets could then be wrapped in a Gtk::Dialog for convenience, but then they could also be dropped into tabbed pages of a notebook, set vertically in a single window, etc. And then in our code, we should try to avoid the physical concept of "pop up the style dialog", and instead replace it with the logical concept of "present the style chooser to the user". That's a very subtle difference, but can help in lots of areas. Also... are there any other components we should come up with? Right of hand I can think of one in the 'Icon Preview' dialog I'm working on. It probably needs an document chooser, much like on the GIMP's layer dialog. However, others might need this too, so I was thinking it would be nice to have it generic and as reusable as the 'current color widget'. Anything else?

5 6

Icon loading changes
by Jon A. Cruz 09 Mar '05

09 Mar '05

I just did a big change in the behavior of Inkscape icons. Funny thing is, it's a net reduction in lines of code. Anyway, now when it goes to build an icon, it first asks GTK+ if there's a stock image of that name. If so, it loads it on up. And it also returns the stock GtkImage instead of a new instance of SPIcon built from an extracted bitmap. One of the things is that now the stock icons being used will reflect the current theme, when before they'd always be the default GTK+ stock icons regardless of what theme was being used. Also... if the theme is changed will the app is open, they stock icons will now change to stay in step. Perhaps we should use more stock icons. Perhaps we should get inkscape ones pushed out into standard stock land. Perhaps we should have nice SVG inkscape theme sets to switch when main themes are changed. Perhaps... Anyway, play around and see what comes up.

8 12