(sorry my gaim keeps segfaulting, no idea why, never used it before... email is more reliable anyway :)
I did a diff between the hydra branch and Sodipodi 0.33 (only /src). It's 450Kb so I cannot even put it on the tracker - maybe put into CVS? Where's the best place?
Anyway, I would propose that everyone would review the diff and delete those parts that are already in Inkscape, or those that make to sense, or are already resimplemented differently, etc. Anything worth transferring should be transferred (and then deleted from the diff). Hopefully we can thus eventually reduce it to zero. I have already removed some small things that I copied to Inkscape.
What I'd like to discuss is this:
- arikkei_* functions are now used extensively all over the codebase, for things like number to string conversions. Are they worth borrowing? What are their advantages compared to atoi and snprintf used before?
- Sodipodi 0.33 can type Cyrillic characters in the text tool. Inkscape cannot. Sodipodi also can display fancy chars such as em-dash (ctrl-u 2014), Inkscape cannot. I think this is due to all the Unicode new stuff in 0.33. We must have this too. Unfortunately it's quite big and complex and I'm not sure I can transfer this correctly. Any takers?
- The "duplicate" checkbox in transformation dialog is nice. It looks simple so I will transfer it (after 0.36 release).
_________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=dept/features&pgmarket=en-ca&RU=http%3a%2f...
On Mon, 8 Dec 2003, bulia byak wrote:
(sorry my gaim keeps segfaulting, no idea why, never used it before... email is more reliable anyway :)
I did a diff between the hydra branch and Sodipodi 0.33 (only /src). It's 450Kb so I cannot even put it on the tracker - maybe put into CVS? Where's the best place?
Could the diffs be broken into sections? E.g., perhaps a diff for each subdir? Reviewing the diff for one subdir sounds like a more easily digestible task, than reviewing a half-gig file. ;-) Then once the section is reviewed, it can be marked done by the doer.
Bryce
On Sun, 7 Dec 2003, Bryce Harrington wrote:
On Mon, 8 Dec 2003, bulia byak wrote:
(sorry my gaim keeps segfaulting, no idea why, never used it before... email is more reliable anyway :)
I did a diff between the hydra branch and Sodipodi 0.33 (only /src). It's 450Kb so I cannot even put it on the tracker - maybe put into CVS? Where's the best place?
Could the diffs be broken into sections? E.g., perhaps a diff for each subdir? Reviewing the diff for one subdir sounds like a more easily digestible task, than reviewing a half-gig file. ;-) Then once the
^ s/gig/meg/ ;-)
section is reviewed, it can be marked done by the doer.
Bryce
On Mon, 2003-12-08 at 00:41, bulia byak wrote:
- arikkei_* functions are now used extensively all over the codebase, for
things like number to string conversions. Are they worth borrowing? What are their advantages compared to atoi and snprintf used before?
They're locale-independent (the locale-dependant nature of the standard library stuff has been a headache particularly for the Win32 port).
I'm not sure how we want to deal with this though ... if we start merging libarikkei, that could easily end up tying us to tracking Sodipodi's libarikkei, of which I'm not very fond anyway.
So, we may borrow some of the code, but I would actually advocate removing libarikkei itself entirely from our codebase.
- Sodipodi 0.33 can type Cyrillic characters in the text tool. Inkscape
cannot. Sodipodi also can display fancy chars such as em-dash (ctrl-u 2014), Inkscape cannot. I think this is due to all the Unicode new stuff in 0.33. We must have this too. Unfortunately it's quite big and complex and I'm not sure I can transfer this correctly. Any takers?
I can at least have a look at it... I think as part of the merge it might be important to understand why it doesn't currently work, too.
Also, this goes without saying, but when merging these large chunks of code we need to make sure that we update copyright statements as appropriate. That may mean some digging into CVS logs at times.
-mental
MenTaLguY wrote:
On Mon, 2003-12-08 at 00:41, bulia byak wrote:
- Sodipodi 0.33 can type Cyrillic characters in the text tool. Inkscape
cannot. Sodipodi also can display fancy chars such as em-dash (ctrl-u 2014), Inkscape cannot. I think this is due to all the Unicode new stuff in 0.33. We must have this too. Unfortunately it's quite big and complex and I'm not sure I can transfer this correctly. Any takers?
I can at least have a look at it... I think as part of the merge it might be important to understand why it doesn't currently work, too.
I can lend a hand looking into this a little. Though it's been ages since I've done MSVC stuff here, I have worked in i18n on and off for the past 10 years.
On Mon, 2003-12-08 at 00:41, bulia byak wrote:
- Sodipodi 0.33 can type Cyrillic characters in the text tool. Inkscape
cannot. Sodipodi also can display fancy chars such as em-dash (ctrl-u 2014), Inkscape cannot. I think this is due to all the Unicode new stuff in 0.33. We must have this too. Unfortunately it's quite big and complex and I'm not sure I can transfer this correctly. Any takers?
If it couldn't even do special characters (despite the unicode entry being present for a long time), it looks like font substitution only just got implemented in libnrtype.
The more I think about it, I think we really need to start migrating away from using libnr/libnrtype/libarikkei.
Otherwise we're in the unenviable position of being stuck with a dependency on strange and undocumented libraries whose sole upstream maintainer who has a history of being unresponsive and going AWOL for months at a time.
So, really I think our plan going forward should be:
1. purge libarikkei from the codebase
2. redo text handling/rendering using Pango over libnr somehow -- this either means figuring out a way to get laid-out glyph outlines from Pango, or implementing a libnr backend for Pango
3. (eventually) replace libnr with Cairo
Practical consideration: if we can pull off the Pango thing, we leapfrog Sodipodi in terms of our text handling.
-mental
MenTaLguY wrote:
- redo text handling/rendering using Pango over libnr somehow -- this
either means figuring out a way to get laid-out glyph outlines from Pango, or implementing a libnr backend for Pango
Easy, you create a pangocontext, put the text (including font and style markup) using pango_context_set_markup in, generate a pangolayout and you can access everything (glyphs, line spacing and extents).
import gtk, gtk.gdk import pango
context = widget.create_pango_context()
pfd = pango.FontDescription("Sans 23") pl = pango.Layout(context) context = pl.get_context() context.set_font_description(pfd)
pl.set_markup("<span fontsize="100">Hello World!</span>")
gtk.gdk.Drawable.draw_layout(widget.window, gc, 0, 0, pl)
njh
On Mon, 2003-12-08 at 23:43, Nathan Hurst wrote:
Easy, you create a pangocontext, put the text (including font and style markup) using pango_context_set_markup in, generate a pangolayout and you can access everything (glyphs, line spacing and extents).
Can you give me an example of extracting the glyph outlines from a pango layout?
-mental
MenTaLguY wrote:
On Mon, 2003-12-08 at 23:43, Nathan Hurst wrote:
Easy, you create a pangocontext, put the text (including font and style markup) using pango_context_set_markup in, generate a pangolayout and you can access everything (glyphs, line spacing and extents).
Can you give me an example of extracting the glyph outlines from a pango layout?
http://www.pango.org/layout.shtml
call this for each run in your layout:
PangoLayoutRun http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#PangoLayoutRun* pango_layout_iter_get_run (PangoLayoutIter http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#PangoLayoutIter *iter);
A layout run is equivalent to a glyph string:
A glyph string is a list of ints, which are indexs into something... I think you use these as indices into a PangoFont and then need to work out how to get the glyph out of freetype.
Ok, I haven't explored that region yet :)
njh
On Tue, 2003-12-09 at 00:33, Nathan Hurst wrote:
http://www.pango.org/layout.shtml
call this for each run in your layout:
PangoLayoutRun http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#PangoLayoutRun* pango_layout_iter_get_run (PangoLayoutIter http://developer.gnome.org/doc/API/2.0/pango/pango-Layout-Objects.html#PangoLayoutIter *iter);
A layout run is equivalent to a glyph string:
A glyph string is a list of ints, which are indexs into something... I think you use these as indices into a PangoFont and then need to work out how to get the glyph out of freetype.
Ok, I haven't explored that region yet :)
Hrm, doesn't look quite as bad as I had thought, actually...
In the case of the Freetype backend, we'd get the FT_Face with pango_ft2_font_get_face(), and I assume we can use FreeType2 facilities at that point to get glyph outlines without too much trouble.
With Win32, we can at least use pango_win32_font_logfont() to get a LOGFONT * structure, but I'm not sure how to get from there to the HFONT we need for use with GetGlyphOutline()...
-mental
participants (5)
-
Bryce Harrington -
bulia byak -
Jon A. Cruz -
MenTaLguY -
Nathan Hurst