- Inkscape Devel - Inkscape Mailman

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

feature request, XY lower-left vs center toggle
by qazxswedcvfrtgbnhyujmkiolp2000 qazxswedcvfrtgbnhyujmkiolp2000 12 May '08

12 May '08

Hi inkscape-devel, A very useful feature for me (and probably others) is to toggle the meaning of the X and Y boxes between object lower left coordinate and object center coordinate. For example, just as there is a padlock button to control whether W and H are locked, there could be an origin button to control whether X and Y are lower left or center coordinate. I want this e.g. for positioning centered text by center coordinate, not lower left. What do you think? qazxswedcvfrtgbnhyujmkiolp2000

2 1

eraser tool feedback
by MenTaLguY 12 May '08

12 May '08

After experimenting with the eraser tool a little bit, I think the best answer to my use case would be to expand the tool to three modes, something like: - Delete - Erase from selected - Erase from all [i.e. all on current layer] Additionally, the tool needs the ability to "reach into" groups when erase. Currently it just leaves the erasure path behind without doing anything if you try to erase a group with paths inside. Also, the dynamic stroke features aren't very useful for erasure, which benefits most from a uniform, controllable shape. -mental

1 0

Annoying Sound
by erkan acar 12 May '08

12 May '08

Inkscape makes a warning sound when backspace is used in the name field at the save as dialog (when the name field is blank). Is it possible to turn off this sound? It is extremely annoying. --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

6 8

Inkscape 0.46 binaries / Zero Install
by Thomas Leonard 11 May '08

11 May '08

Hi, I normally add a link to an Inkscape binary (either the RPM or the Autopackage, whichever turns up first) in the Inkscape Zero Install feed: http://0install.net/2006/3rd-party/Inkscape.xml However, there don't seem to be any Linux binaries this time, so I have added the source to the feed and compiled two binaries myself (x86 and x86_64). These can be run using this command: 0launch http://0install.net/2006/3rd-party/Inkscape.xml The correct binary for your platform will be selected automatically (ensure "Help test new versions" is on, or you'll get 0.45). The 0launch command is provided by most Linux distributions, or you can get it from: http://0install.net Alternatively, you can use the binaries without using 0launch by going to the web-page above and clicking on one of the download links. The binaries are compiled with binreloc on, so you can run them directly after unpacking. I've tested them on Ubuntu/Hardy, but I don't know if they'll work on anything else. To choose a different version or compile from source: 0launch -g http://0install.net/2006/3rd-party/Inkscape.xml When compiling (right click -> Compile), Zero Install will download the headers for GTK, GLib, Pango, ATK, GTKmm and GLibmm automatically. However, some other libraries are not available this way and must be installed manually first as root, e.g. $ sudo apt-get install build-essential gettext libpng-dev libgc-dev libfreetype6-dev liblcms-dev libsigc++-2.0-dev libcairo-dev libcairomm-1.0-dev libxslt-dev libboost-dev libpopt-dev Hope that's useful! PS: The Zero Install feed is currently listed under "Development Versions" on http://inkscape.org/download. In fact, it only lists official releases, so it should be moved to "Official Release Packages". Cheers! -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1

1 0

Re: [Inkscape-devel] [Lib2geom-devel] Nameclashing with is_finite macro
by unknown＠example.com 10 May '08

10 May '08

> -----Original Message----- > From: njh [mailto:njh@...1927...] > Sent: zaterdag 10 mei 2008 20:25 > To: Engelen, J.B.C. (Johan) > Cc: lib2geom-devel(a)lists.sourceforge.net; > inkscape-devel(a)lists.sourceforge.net > Subject: Re: [Lib2geom-devel] Nameclashing with is_finite macro > > On Sat, 10 May 2008 J.B.C.Engelen@...1578... wrote: > > > Hi all, > > > > I am having troubles with the is_finite 2geom macro. In > Inkscape code, > > there are cases where an is_finite function is defined > (proj_pt.h for > > example). This goes okay now, only because no 2geom headers are > > included before that header is included. If the isnan.h header is > > included before proj_pt.h, the compiler will place the > is_finite macro > > in the function definition and compilation will fail. (on > windows in > > any case) > > > > I see 2 options: > > 1. change the is_finite function name in proj_pt.h 2. change the > > is_finite macro name in 2geom/isnan.h to something less clashable > > 3. Namespaces? I think macro's don't have namespaces. > 4. Considering they are in fact the same function (copied), > why not add a test for existence and use the same name? They are not the same function: proj_pt.h => "inline bool is_finite() { return pt[2] != 0; }" is not like the std:isfinite which takes an argument. -johan

1 1

Temporary Bitmap Display Help in New Tool
by Keith 10 May '08

10 May '08

I'm busy developing a cool new drawing tool for Inkscape (one that I've been dying to implement since using Inkscape :D ), the core is pretty much finished, but I'm running into a bug which can be resolved by implementing a feature of the tool that I have no clue on how to achieve :( . My tool creates a GrayMap when the mouse button is pressed, updates it as the mouse is moved then processes and destroys it when the mouse button is released. I need to be able to show the GrayMap, any other kind of bitmap will do, on the canvas and then hide it when not used. How can I do this? I've been looking around and I can't find any examples in the existing code that does something like it. I'd really appreciate any help guys. Thank you.

2 1

not-set behaviour of some attributes
by Felipe Sanches 10 May '08

10 May '08

I am working on the parameter loading code for svgfonts. Some attributes of the font-face tag are specified to behave in special ways when not set. One example is this couple of attribute: accent-height = "<number>" The distance from the origin to the top of accent characters, measured by a distance within the font coordinate system. If the attribute is not specified, the effect is as if the attribute were set to the value of the ascent attribute. If this attribute is used, the units-per-em attribute must also be specified. Animatable: no. ascent = "<number>" Same syntax and semantics as the 'ascent' descriptor within an @font-face rule. The maximum unaccented height of the font within the font coordinate system. If the attribute is not specified, the effect is as if the attribute were set to the difference between the units- per-em value and the vert-origin-y value for the corresponding font. Animatable: no. Is there already a established good practice to deal with this kind of thing on the inkscape codebase? I suppose that a good solution would be to implement a container template-class which would take care of the set/unset state of the stored object (in these cases, a double) and a method to compute the nonset value, sometimes refering to the value of other objects. In these cases, it would refer to an ascent object for the computation of a not-set accent-height attribute and both vert-origin-y and units-per-em objects for the computation of a not-set ascent attribute. Am I right? Does this already exist on the codebase? Should I implement it this way? Juca

2 1