- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] adaptiveThreshold.cpp:20: error: 'image' was not declared in this scope
by Bob Jamison 14 May '08

14 May '08

Is this using the "prefix:" attribute in the .pc file correctly? bob >>>> /usr/include/ImageMagick/Magick++.h >>>> >>> This is non-standard. It can be correct, but I'm guessing this command >>> returns the same thing it does for me: >>> >>> $ pkg-config --libs --cflags ImageMagick++ >>> -lMagick++ -lWand -lMagick >>> $ >>> >>> Which basically means the ImageMagick++.pc file is incorrect on your >>> system. I think the more standard installation is to have Magick++.h >>> in /usr/include, but I can understand someone wanting to change it. But >>> that person needs to update the package config script too or compiles >>> will break :)

1 0

PDF import crash, but not in 0.46
by unknown＠example.com 14 May '08

14 May '08

Hi all, PDF import crashes for me on Windows with current trunk. It does not crash in the Inkscape 0.46 binary that I just downloaded. Have all windows patches been applied to trunk? Thanks, Johan

2 2

Request for translation SVN commit rights
by Domas Jokubauskis 14 May '08

14 May '08

Hello, I have been using Inkscape for a couple of years now and it have been a great experience. Thank you! I'm passionate about getting proper Lithuanian language user interfaces so I did a substantial update of Lithuanian Inkscape translation for version 0.45.1. I would like to continue my work on future releases but sending changes to the mailing list and asking others to commit them is counter-productive. Thus, I would be grateful if the project's admins granted me the permission to commit changes to lt.po file. My SF.net e-mail: domasj@...58... -- Domas Jokubauskis DomasJ@...1970...

2 1

unicode<->glyphid mapping
by Felipe Sanches 13 May '08

13 May '08

I am working on nr-arena-glyphs.cpp there, at line 468: NRArenaGlyphs *g = NR_ARENA_GLYPHS(child); g->glyph holds an integer (the glyph id). As I understand it, there must be a mapping between a unicode char and its respective glyph id. How can I retrieve it? Juca

2 1

Re: [Inkscape-devel] SVGFonts: lot's of questions
by Richard Hughes 13 May '08

13 May '08

> The font data can all be fed to cairo using the user-font support that I > committed to master last week. So you have some code to write already. > You need to provide the render_glyph(). If you don't have kerning, > providing unicode_to_glyph() would be enough, but for kerning, you need > to use the full text_to_glyphs() method. > The Pango bits to make pango use cairo user-fonts don't exist yet. This > is the bug tracking that: > http://bugzilla.gnome.org/show_bug.cgi?id=347237 > While I want to fix that bug this cycle, I don't have a estimate for it > yet, and it's not on my plate for the next few weeks... Reading through that bug I'm unclear whether the proposed pango_font_description_set_domain() function could be used to support a user-font which wasn't also a Cairo user-font. Could you clarify whether it intended to be able to use this feature without being required to use Cairo? Richard.

1 0

Re: [Inkscape-devel] SVGFonts: lot's of questions
by Gail Carmichael 13 May '08

13 May '08

Looks like that pango stuff would probably help what I was doing, too. I never got to worrying about rendering fonts, just representing them in the SVG file. On Tue, May 13, 2008 at 2:24 PM, Behdad Esfahbod <behdad@...1866...> wrote: > On Tue, 2008-05-13 at 14:54 -0300, Felipe Sanches wrote: > > > > What is needed to make inkscape render this? I suppose that I should > > provide the kerning info to cairo userfonts and then cairo-user-fonts > > would call my glyph-rendering functions providing me the proper x,y > > coordinates. But how do I enable this behaviour just for Super Sans > > font? I guess there must be a way of registering new fonts with pango. > > I just don't see exactly how these pieces fit together. > > The font data can all be fed to cairo using the user-font support that I > committed to master last week. So you have some code to write already. > You need to provide the render_glyph(). If you don't have kerning, > providing unicode_to_glyph() would be enough, but for kerning, you need > to use the full text_to_glyphs() method. > > The Pango bits to make pango use cairo user-fonts don't exist yet. This > is the bug tracking that: > > http://bugzilla.gnome.org/show_bug.cgi?id=347237 > > While I want to fix that bug this cycle, I don't have a estimate for it > yet, and it's not on my plate for the next few weeks... > > Hope that helps. > > -- > behdad > http://behdad.org/ > > "Those who would give up Essential Liberty to purchase a little > Temporary Safety, deserve neither Liberty nor Safety." > -- Benjamin Franklin, 1759 > >

1 0

buildtool again
by Bob Jamison 13 May '08

13 May '08

Hi again. I left something out of buildtool yesterday, that broke the cross-compiler build on a linux box. Buildtool was not handling recursive substitutions, like: a = "Hello, ${b}" b = "earth, the third ${c}" c = "planet" This is slightly more work to do at execution time than at read time. command="${archutil}windres" archutil="${arch}" arch="i686-pc-mingw-" ...was not working. But it's fixed now, and has that pleasant late-binding smell. Sorry if this broke any cron jobs out there. ALSO: Does anyone know what might be causing this warning? I was afraid to touch it: http://rafb.net/p/34eJBu54.html bob

1 0

Fwd: CSS fonts only?
by Gail Carmichael 13 May '08

13 May '08

Below are some excerpts from my conversation with the Pango folks. Not the whole conversation, but will hopefully help Juca out a bit with his project. Gail ---------- Forwarded message ---------- From: Gail Carmichael <gail.banaszkiewicz@...400...> Date: Fri, Mar 21, 2008 at 2:14 PM Subject: Re: CSS fonts only? To: cfynn@...240... Cc: gtk-i18n-list <gtk-i18n-list@...45...> Thanks for the responses, everyone. I just got into a busy spell at school again, but later on I will need to look into this more. It sounds to me that, basically, we shouldn't be using that PangoFontDescription structure in memory to represent our fonts? Unless that changes (either the options the structure can represent or the fact that Inkscape relies on it so much), we will be stuck with the fonts it can represent. I will probably be back more a bit later to ask questions :) Gail Christopher Fynn wrote: Gail Carmichael wrote: Hi Christopher (and others)! Basically what I am saying is that the enumerations defined here <http://library.gnome.org/devel/pango/unstable/pango-Fonts.html><http://library.gnome.org/devel/pango/unstable/pango-Fonts.html>, like the variant, for example, have a specific subset of values. I just happened to notice that the defined values are pretty much equivalent to allowable CSS text attributes. In Inkscape, we use the PangoFontDescription pretty extensively. It is how font information is stored in memory while the program is running, for example. The problem is that some fonts have, say, a swash variant, which cannot be described with CSS text attributes, and also cannot be described with any of these enumerations in Pango in terms of the PangoFontDescription. Instead, the regular face of a font family is used (as a default fall-back), and "fancy" fonts are thus not accessible in Inkscape. Gail My guess is the best way to handle this w Pango would be through OpenType features & lookups i.e. to include the swash variant glyphs in the base font and have those accessed through OpenType features and lookups - which could be either contextual or user selected. Having *separate* alternative "fancy" fonts with swash / small caps / etc. fonts is the old way of doing things - if you think about it that way, is much more limited. For user selected / discretionary OT features the application (Inkscape) would need some kind of interface /menu through which the user could apply the features she wanted to. WRT CSS - there has been some serious discussion off and on over several years (on the OpenType list, CSS related lists and other places) about specifying - or applying OpenType features through CSS. regards - Chris Hope that clarifies what I am trying to say. It would be cool to pretty much just add more values to the enumerations (and supporting code) so more varieties of fonts could be described. I wanted to know what you guys thought of that possibility - is there some technical or philosophical reason, as can sometimes happen, for not doing so? Thanks Gail ------------------------------ *** VIRUS SCANNED by FASTLINK ISP ***

1 0

Update to buildtool for win32
by Bob Jamison 13 May '08

13 May '08

Hi, all. Over the weekend, I noticed a big flaw in Buildtool. The property aliasing, such as: path="{$gtk}/lib" ...was done at file-read-time. This made it impossible for a Task to use the results of another task as input. So all of the Tasks were recoded to have late binding. Package-config now works. To query a package, just use ${pc.packageName} for the 'all' query, ${pcc.packageName} for the 'cflags' query, and ${pcl.packageName} for the 'libs' query. Note that this is processed internally, and does not call the pkg-config executable. It also grabs all dependent packages' queries, too. This is in addition to the existing: ${env.VARIABLE_NAME} to fetch an environment variable. I did a test build, and it seems to work ok. Please let me know if there are any problems. After you svn up, you will need to do: g++ buildtool.cpp -o btool.exe ...again, for btool to use build.xml properly. bob (ishmal)

2 1

CSS for SVGFonts
by Felipe Sanches 12 May '08

12 May '08

During this weekend I have spent some time coding parameter loading for the font-face tag. Then, after commiting (http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=18594), I noticed that style.{cpp,h} contain code that partially implements the same thing. So, I supose that I will have to revert what I did and use face->style to access the content of those attributes (such as font-style, font-variant, font-stretch, etc). Although, I have also noticed that not every attributes described on CSS2 spec, section 15 (Fonts) are implemented. For example, none of the attributes on section 15.3.6 ('panose-1', 'stemv', 'stemh', 'slope', 'cap-height', 'x-height', 'ascent', and 'descent') seem to be implemented. What should I do? Should I implement them in SPStyle? Or should I implement it on SPFontFace ? Juca

3 2