Duplicating libcroco code in Inkscape tree
by Peter Moulder
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.
18 years
icon issues
by bulia byak
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
18 years
icon preview?
by bulia byak
Jon,
what is this new icon preview dialog? Is it temporary?
18 years
New text layout code
by Richard Hughes
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.
18 years
printing
by herve couvelard
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é
18 years
Re: [Sodipodi-list] Re: I can't admin the project after all
by Jon Phillips
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)
18 years
No more dialogs!!!
by Jon A. Cruz
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?
18 years
Icon loading changes
by Jon A. Cruz
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.
18 years
Icon preview
by Jon A. Cruz
It's a little buggy, but go ahead and check out the initial cut of "Icon
Preview" under the View menu.
I mainly just put stuff I needed for debugging into a dialog. Just hit
"refresh" and it will render the top desktop's selected item as icons in
different stock sizes.
18 years
