- Inkscape Devel - Inkscape Mailman

RE: HELP!!! was: Re: [Inkscape-devel] importing bitmaps as patterns
by bulia byak 27 May '04

27 May '04

>After reading it I noticed, that it just is the new expressions for the >non-zero and even-odd fillrule. >I don't understand "alternating" vs. "winding", though. "alternating" >makes sense, but "winding"? I'll try to come up with some more >self-explainatory expression. Actually winding is a common term for this fill. Google it. And actually, I'm going to change this menu into a couple of toggle buttons (to the right of the solid/gradient fill buttons) so it will be more graphic and easy to understand, plus it will take less space. _________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: HELP!!! was: Re: [Inkscape-devel] importing bitmaps as patterns
by bulia byak 27 May '04

27 May '04

>I don't know, could you just tell me, what this is about? I tried to fined >"store" in the tuts, but there nothing, it seems. Ctrl+Shift+P > Transforms > Store transformation: Preserved _________________________________________________________________ Add photos to your e-mail with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: HELP!!! was: Re: [Inkscape-devel] importing bitmaps as patterns
by bulia byak 27 May '04

27 May '04

>On Wed, 2004-05-26 at 15:43, bulia byak wrote: > > >1) The image's top-left is not aligned with the rect's top-left. > > >Currently > > >the image's top-left is (usually) in the center of the rect. > > > > Works for me. Can you provide an example? > >I can confirm this behaviour... Have you set Store transforms to Preserve? > > 2) When the rect is grown, the image is tiled to fit the rect. It > > >should cover > > >the rect exactly and completely -once-. > > > > Oh, again, this is A BUG to be fixed :) I have specifically noted that >you > > need to Store tranasforms: Preserved as a workaround for now. If this >still > > happens with Preserved, I want to know details. > >IMHO this actually is not a bug! We're talking about _patternfill_. >That's what a patternfill is supposed to do! No. By default fill is transformed together with the rect. This is what happens now when you set Store transforms to Preserve. >also want the pattern to scale with the object, when ctrl is pressed >while scaling. Eventually this will be the default that will work in all modes. You'll be able to turn it off if you wish but this is the default behavior. And it works now if you set Store transforms to Preserve. > > I honestly haven't looked at transparency in particular, but I remember >that > > it didn't work for <image> either when I tried it. I'll investigate. > >I don't quite understand. The rect should have no fill, and by default >doesn't. if I want to alpha-blend the image, I just use the >object-dialog and ajust the the opacity of the rect. >What am I missing here? The image may have its own transparency, such as alpha shannel in PNG. >What I'm criticising is that you eventually give up the idea of a >patternfill, to make a workarround for clipping paths. >I don't know about you, but I think, whose of you who do the coding will >end up throwing all this stuff away pretty soon because real clipping >paths are implemented. No it won't end up thrown away. Clipping paths are an entirely different story. _________________________________________________________________ Free yourself from those irritating pop-up ads with MSn Premium. Get 2months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: [Inkscape-devel] rect improvements
by bulia byak 27 May '04

27 May '04

>I don't know, but I downloaded yesterdays cvs, have the >patternfill-import-image-stuff (which I didn't have before cause I >hadn't upgraded for quite a while) but don't see any changes to the >behaviour of the rect, nor do I see the handle you're talking about. Is >my build broken? Did you forget to commit the changes to cvs? >I'd love to tell you if it's the way I though it should be and am >confident that it is, but right now I can't yet. Oh my, I always forget that anonymous CVS lags behind. Just wait a day and try again. _________________________________________________________________ Add photos to your messages with MSN Premium. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

Re: [Inkscape-devel] rect improvements
by bulia byak 27 May '04

27 May '04

I got some ideas of further rect improvements, but I want to discuss them here first. Now the rect tool stores the relative radii of corners, so if you set one rect with a 0.3 ratio of radius to the half-side, the same ratio will be applied to the next one. So the subsequent rects you create will be "scaled versions" of the first one, and their absolute corner radii will be different if their height/widths are different. What I think will be more useful is to store the absolute radii instead, so that new rects you create have the same radii even if different height/width. In fact, I propose to do away with the ratios altogether, so that the absolute values of radii are preserved even when you scale a rect with selector. So you'll be able to scale or transform a rect arbitrarily and it will keep the same rounded corners throughout (the only exception is when you scale it down so that its side is less than twice the radius, in which case the raidus will be trimmed); if you want to change the corner radii, the rect tool will let you do that in absolute units (mm, pt, etc.). I will at least implement this as an option, but my question is, does anyone else think that this should be the default or even the only behavior? I also like the idea of being able to copy/paste corner radii along with the rest of the params with Paste Style. This will require some additional coding because the rx and ry attrs are not part of the style, but for the user it will be transparent. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN Premium http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

2 1

RE: HELP!!! was: Re: [Inkscape-devel] importing bitmaps as patterns
by bulia byak 27 May '04

27 May '04

>Though: in the fill dialog I can change between alternating and >winding... what does this do? We spent quite some effort packing the explanation of that in the tooltip :) Hover your mouse over the menu, and post to the list if you feel the tooltip is in any way unclear. _________________________________________________________________ MSN Premium includes powerful parental controls and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

rect improvements
by bulia byak 27 May '04

27 May '04

* The rect now has one more handle in the bottom right corner which allows you to resize the selected rect without switching to selector. Also unlike selector, resizing by this handle preserves the absolute values of the rounded corner radii (as opposed to the radius/width and radius/height ratios). The handles for rounding corners are moved to the top right corner. Also while at it, I implemented this RFE: http://sourceforge.net/tracker/index.php?func=detail&aid=933672&group_id=93… and made it so that equal-radii rounded corners are always applied as such when new rects are created. David, please check and report if it's to your liking. _________________________________________________________________ MSN Premium with Virus Guard and Firewall* from McAfee� Security : 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 2

RE: HELP!!! was: Re: [Inkscape-devel] importing bitmaps as patterns
by bulia byak 27 May '04

27 May '04

>1) The image's top-left is not aligned with the rect's top-left. >Currently >the image's top-left is (usually) in the center of the rect. Works for me. Can you provide an example? 2) When the rect is grown, the image is tiled to fit the rect. It >should cover >the rect exactly and completely -once-. Oh, again, this is A BUG to be fixed :) I have specifically noted that you need to Store tranasforms: Preserved as a workaround for now. If this still happens with Preserved, I want to know details. >2) Image transparency is broken. The background of the rect is copied >onto >whatever is behind it. I do not know how to fix this. If the >image it placed upon an invisible rect, isn't the entire image invisible >also? The rect would have to be 0% opaque on the transparent parts, >and whatever the user wants on the rest (default 100%). It would >basically need to be a matte fill, or the alpha-blend algorithm. I honestly haven't looked at transparency in particular, but I remember that it didn't work for <image> either when I tried it. I'll investigate. >This is a great idea, but I can't use it right now. I'd like to keep >using the current CVS, but is there a way I can back this change >out just for myself? Set options.importbitmapsasimages to 1 in your preferences.xml. Better yet, stay in the new mode and help us debug it :) _________________________________________________________________ Free yourself from those irritating pop-up ads with MSn Premium. Get 2months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 2

re: bitmap as patterns
by Cédric GEMY 27 May '04

27 May '04

Wow, I didn't see that. I've to try. Does it mean this could also be a beginning state to add clip and mask on the shapes and path, such as described at http://www.w3.org/TR/SVG11/masking.html ? Cedric

2 1

Re: font metrics
by MenTaLguY 27 May '04

27 May '04

On Tue, 2004-05-25 at 02:54, fred wrote: > the fact that the work needed is still a bit blurry > probably doesn't motivate people; also, i'm less and > less sure of the first step you put in the roadmap > that consists of doing a pango libnrtype backend to > eat libnrtype from the inside; libnrtype main use is > to get glyph outlines and advances, something i cannot > get pango to spit. on the other hand, > nr-type-directory and nr-typeface are almost 1/1 > mappings to PangoFontMap and PangoFont That's about right; the plan is: 1. C++ify libnrtype to make it easier to refactor 2. introduce an NRTypeFace subclass that wraps PangoFont (and hides any platform/pango-backend-specific details) 3. remove the other NRTypeFace subclasses 4. jettison NRTypeDirectory and NRTypeFace, using Pango directly (moving any facilities not directly provided by Pango into a separate set of C++ classes) To get glyph outlines and advances in Pango, you need to use backend-specific functions to get a "font handle" native to the underlying API (e.g. Freetype or Win32). IIRC, PangoGlyph in turn is just an integer containing the native font glyph index. At that point you can use the "native" API to get what you want. Of course, SPTypeset, SPText etc. should not have to care about the native API; the intent is that the NRTypeFace subclass in #2 and later the supplemental classes in #4 will provide an API hiding those details. Part of the reason for the gradual approach is that there are a lot of (potentially important) minor tweaks in libnrtype (e.g. the special unicode mapping Lauris added for "symbol fonts" for Lilypond-generated SVG); we want to understand all the code we're replacing so we won't have regrets later. Another reason is so we can easily evaluate Pango without causing the breakage a wholesale replacement would. For example, I think the freetype backend should work on Win32 (i.e. it should pick up the Win32-installed fonts), but we need to make sure there aren't any gotchas. (an ideal goal is to get the same code working on Win32 and Unix, but we have yet to see if that is possible..) If at that point all the changes are "contained" by the libnrtype API, if it turns out to work badly, we can switch to using the win32 pango backend on Windows without disrupting the rest of the code. > isn't such info already contained in a glyph string? > maybe diacritical marks have a special treatment (0 > width, x_offset and y_offset?) in pango, i dont seem > to locate rasterization-specific stuff for arabic; > once the text has passed through the shaper, the > glyphstring doesn't change. Yes. I think I misunderstood the stages of Pango before. Doesn't the shaper output include the advance, then? -mental

1 0