Re: [Sodipodi-list] Two Issues (Bugs?)

[Lauris K. <la...@xi...>]

Hello!

On 25 Jun 2001 13:42:50 +0200, Aschwin Gopalan wrote:
> I just played a little with sodipodi (fresh from cvs). I was courious how
> difficult it would be to include support for <tspan>? It would be nice
> to have markup inside Text strings. I tried the following: I created a
> Text and added <tspan style="fill:red;">Text</tspan> using the Text
> property widget. The I saved and tried to view the svg in Batik. 
> Batik complained that fill-opacity shouldn't have percentage values. I
> took emacs and changen all fill-opacity:100% to fill-opacity:1 and it
> worked! 
> 
> So: From reading the SVG specs, I think its a bug to use percentage values
> in fill-opacity and stroke-opacity. Sodipodi reads the correct values o.k.
> but saves wrong. Should be easy to fix, should I take a try? 

Yes, do it, if you dare ;-) The (somewhat incomplete) code is in
src/style.c (style parsing and writing).
Actually I wonder how much SVG spec has changed between the start of 
sodipodi (near 2 years ago) and today. I find myself now and then
little fancy incompatibilities, about which I still remember, how I read
SVG spec about these ;-)

> I think, strings edited in the Text-Property widget should probably be
> escaped, because when i enter something like the above, sodipodi is not
> able to read its own file correctly because of the missing <tspan>
> support. 

Yeah.
Actually text support is mostly crap anyways. It is hardcoded 
iso-8859-1, and does not escape anything (including '&'), due
to the problems with libxml1. Writing decent support with current
libxml would create broken files (that are read back good by
libxml1, but create error with any conformant xml library). This
will be resolved by libxml2, that is part of gnome2, but unfortunately
cannot easily used from gnome-1.4 framework due to symbol name
clashes.
But as soon as we can start migrating to gnome2 platform, there will
be meaningful (incl <tspan>) text parser, utf-8 support and other
goodies.

> Are there plans to support Rich Text? I would try to help, can you show
> me the right places to start (I would think that one would start with
> the SVG renderer?)

If you can think out, how to implement that...
I'd very-very much like, if sodipodi text support would not be limited
by latin and like languages, but would include arabic, hebrew, various
nagari based scripts etc. There is library in gnome-2 (Pango), that can
do much dirty work, but I am not sure, how exactly it would be
possible to interface it with sodipodi. But text widget of gtk 2,
for example, is capable for inputting multi-language, multi-script
text, with font and color changes. So I think it would be too much
work to implement that with gtk 1.2. But what is still needed, is
framework for new text object in sodipodi.

Current text object class hierarchy is:

SPShape -> SPChars -> SPText

Shape is arbitrary shape (rects and ellipses are also subclasses of 
shape). Chars is series of positioned characters (need not to be
in line). Text is just text.
To support rich text, I see 2 possibilities:

1. Subclass group somehow - i.e. each differently styled part of text
   is separate object, dynamically generated from text associated
   with base object.

2. Write much richer SPChars object. This should be easier to implement.

I am not very happy with current inheritance model and plan to break
texts free from SPShape. This would make writing text objects a bit
harder, but removes lots of ugly complexity from ordinary shapes.

> Another unrelated question. I think, Postscript printing could be improved
> a little. It would be nice to be able to specify the resolution at which 
> the bitmaps for transparency simulation are generated. I tried to 
> use png export, but the colors where all off (at least when I viewed the
> png in Gimp).

The resolution is currently the function of gnome-print, not sodipodi.
Yes, it is hardcoded to 72 dpi - the right solution needs quite capable
printer configuration framework - which is implemented in gnome-print
HEAD to some extent.
Still there should probably be separate export to EPS function. This
could be done with gnome-print, but maybe would be better to do that
independently.
But the png export should be fixed if it is broken...

Best wishes,
Lauris Kaplinski