February 2004 - Inkscape Devel

Reminder on IRC Scribus and Inkscape or Inkscape and Scribus ;)
by Peter Linnell 29 Feb '04

29 Feb '04

Hi all, To clarify: IRC meet at #scribus on freenode.net 07:00 CET Sat 28 Jan. = 1 AM EST or 10 PM PST. Fri. PM Please review the notes at: http://www.inkscape.org/cgi-bin/wiki.pl?ScribusInteroperability Thanks and look forward to this. Peter

5 10

Re: [Inkscape-devel] xft font fixes
by bulia byak 29 Feb '04

29 Feb '04

>This is probably unrelated, but I am getting a segfault on nr-type-w32.cpp Hi Bob, this is now fixed, fonts work again on win32 at least as they used to (plus with styles sorted in the list). However when I tried to make it correctly display Cyrillic font names, I found that g_locale_to_utf8() does not work (even though g_locale returns the correct locale, CP1251). The error returned by the conversion function says "Error during conversion: no such file or directory" (code 2), which suggests that it requires some external module or table which is not included with your GTK or Glib files. Could you please check this, and add anything necessary for conversion functions to work? _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjo…

3 2

Re: [Inkscape-devel] inverse handles
by bulia byak 28 Feb '04

28 Feb '04

>Just to clarify, "as they used to" refers just to the final visual result >if the background is white, it doesn't mean using semi-transparency: >just as currently we don't do "pure" inversion (especially when the >background is near 50% grey), we can similarly tweak the function >to give a given image as the background approaches white. OK, now the function is (in helper/sodipodi-ctrl.cpp): #define COMPOSE_X(b,f,a) ( ( ((guchar) b) * ((guchar) (0xff - a)) + ((guchar) ((b ^ ~f) + b/4 - (b>127? 63 : 0))) * ((guchar) a) ) / 0xff ) where b is background, f is foreground, a is alpha. Propose your own and we'll compare. >which the default style is decidedly bad. E.g. inversion is bad for >very noisy background: inverting noise is still noise. The goal of the handle is not to turn noise into non-noise. Its main goal is to be visible. With inversion, it fails to be visible only when it overlays an object which is a copy of the handle, i.e. has inverse color relative to the surroundings and has the same shape. The probability of this is close to zero. Any other noise is not an obstacle to it being visible with inversion. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2f%2fjoi…

3 2

IRC Logs
by Peter Linnell 28 Feb '04

28 Feb '04

Hi all, First, I think it is fair to say it was a very promising start at cooperation and many many good things will come from this in the future. For those unable to attend or had connection problems, I have posted the log (60k) at: http://www.atlantictechsolutions.com/inkscape/28022004.log Cheers, Peter

1 0

Re: [Inkscape-devel] further font problems
by bulia byak 28 Feb '04

28 Feb '04

>however when I skimmed it a little while back I recall noticing that there >were many problems with font info getting collapsed to simple strings when >there were more details in the info available. Yes, simply because CSS requires such collapsing. That's the point. Jon: Do you know if there's any progress with bug 866197, "problems with non-ascii filenames"? There was some activity in file-related areas recently, but I'm not up to date on the current status. _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

further font problems
by bulia byak 28 Feb '04

28 Feb '04

Now that Inkscape can see all font styles, futher problems emerge. The biggest problem is that SVG uses CSS, and the premise of CSS is different from that of a design app. CSS was designed to get "as close as possible" font rendition on a wide variety of platforms. The goal of a design app is to render the font _exactly_ so long as it is available on the system. The font selection properties used by CSS include family, style, weight, variant, and stretch. Each property has a fixed limited set of values: http://www.w3.org/TR/SVG11/text.html#FontPropertiesUsedBySVG Of these, currently supported by Inkscape (to some extent) are only style (italic or normal) and weight. However, even if all these properties are fully supported, Inkscape _would still be unable to reproduce some fonts_. Take a look at the list of fonts in the Caslon family here: https://sourceforge.net/tracker/index.php?func=detail&aid=904962&group_id=9… It has many variants that CSS simply cannot handle: Swash, Alternates, Old style figures, Expert, etc. I think it is unacceptable for Inkscape to ignore any fonts simply because CSS cannot describe them appropriately. So, I think the only acceptable (although unelegant) solution is to introduce a two-tier font specification. Namely, I propose to introduce <text> attributes inkscape:font-family inkscape:font-style that will hold the family and style exactly as reported by the OS, without attempting to parse them into weight, stretch etc. These will have precedence over CSS in Inkscape and will allow it to reliably use any installed fonts. For non-Inkscape renderings, the CSS specification will work as before (although it probably needs to be improved to handle more of the CSS properties and values). Comments? _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1

Re: [Inkscape-devel] RE: yet another patch
by bulia byak 28 Feb '04

28 Feb '04

Thanks a lot, I committed your patch. We're excited about it because the old rasterizer was a sore spot, it was buggy and so cryptic that no one could really debug it. Your code is much easier to understand and improve. I hope we'll be able to optimize and further develop it. P.S. Let me know if you want CVS write access again. >From: fred <yafoyah@...48...> >To: bulia byak <archiver_1@...19...> >Subject: Re: [Inkscape-devel] RE: yet another patch >Date: Sat, 28 Feb 2004 00:54:36 +0100 (CET) > >a little modification that will make rasterization a >tad faster on some shapes (but not all). >the bug you have i cannot reproduce (same zoom same >file doesn't exhibit any problem), nor guess where it >comes from, sorry... > > > > > >Vous manquez despace pour stocker vos mails ? >Yahoo! Mail : 6 Mo gratuits ! >Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ > >Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez >Yahoo! Messenger sur http://fr.messenger.yahoo.com ><< modif.tar.gz >> _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

RE: [Inkscape-devel] paste: ctrl+v
by bulia byak 28 Feb '04

28 Feb '04

>I rather use the import funktion, because that way I maintain the >gradients. That's true, but gradients will be ultimately fixed. >So as long as gradients aren't working, with copy paste >between documents, it doesn't really though, because I still would want >it to paste to where it was before most of the times. If you are creating many documents which are very similar in layout, then yes, paste-in-place may be needed more often. But it's a special case, not applicable to most regular work. >I don't always want to duplicate stuff... I usually need crtl+v when >trying to substract one object from several others. That is, you just want an object to be on top for subtraction? That's even easier, press Home and it will come to top without duplication. >so another possibility would be to have an option: maintain 'object >subtracted'. Don't understand this one, please elaborate. > > All vector apps I know paste into the current work area, not in the >original > > place. It's kind of like in text editor: when you paste text, you want >it to > > appear at your cursor, not in its original location, right? > >Sodipodi doesn't :) Sodipodi does oh so many things wrong with regard to usability. If we agreed with Sodipodi we wouldn't fork :) >in Illustrator I think you can change the settings Not in version 9 that I have, at least. It has regular Paste (ctrl-v) which places the object in the center of the window, plus Paste in Front and Paste in Back commands that paste in the original place. I think the two latter commands are not really necessary, one Paste in Place in enough. And the fact that Inkscape pastes at the mouse cursor position (and only if the cursor is outside the window, it pastes to the center of window) is I believe a further improvement over Illustrator. >and I don't know about Corel, but I believe it doesn't either, because >doublicate doesn't paste in the same place as standard and I think I >used copy-paste instead most of the time to have a doublicate at the >same place. If Corel doesn't have a workable Duplicate, it's not a reason for _us_ not to have convenient Paste :) >I've never seen that behaviour before, perhaps it makes sense, I can't >tell right now, because nobody ever used it, either because it's crappy >or because nobody ever thought of it. Besides Illustrator, Xara X also pastes in the middle of window by default (but has a Paste in Place command). So it's far from "nobody ever". _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

1 0

RE: [Inkscape-devel] [Fwd: Re: Inkscape 0.37 Released! Try it out!]
by unknown＠example.com 28 Feb '04

28 Feb '04

> From: "Jonathan Phillips" > I think we really need to get OS X DMG files, or an installer for OS X > releases. The majority of OS X folks do not understand > ./configure;make;make install. I agree. This would be good. Of course, who now will be able to do it? :-) According to the Wiki http://www.inkscape.org/cgi-bin/wiki.pl?MacOSXPort There is at least one person with a build machine available. I don't quite have the time to commit to it (due to all the other todo's on my list), but I would be able to test such a DMG whenever a build is done. Jon, maybe you should catch MrDocs on Jabber.

3 2

Re: [Inkscape-devel] inverse handles
by bulia byak 28 Feb '04

28 Feb '04

> > I made the selector handles inverse and tweaked their shapes a bit. > > Some of the colors of node edit and shape knots are also changed. > > Comments welcome. > >I find the handles in CVS at present (2004-02-27) uglier than the blue >handles in the usual case of white background. The one other person I've >asked agrees. Any other opinions? Everyone please speak up! >Can we change things such that on a white background things look as they >used to? Not unless I'm forced by popular vote, and in that case I'll have to patch my copy to have inversion anyway. Or implement handle styles so everybody could use what they like best. You know, the point of having these hamdles is not so they are "beautiful". The point is that they are intuitive, immediately visible, and immediately recognizable. As a person who spends hours in Inkscape doing real design work, I am of the opinion that inversion helps immensely. At first I thought that the new handles are maybe a bit too bright and large, but after some time I grew to appreciate their visibility. >If the only non-white part of the background is overlap with thick black >stroking (say 8--20 pt), then inversion is annoying (distracting) rather >than helpful. On the contrary, in such cases inversion helps me not lose track of the image. It just takes some getting used to - after some time your brain switches to the "inverse mode" and learns to abstract the handle and the background into different planes of perception, so they never obscure or damage each other. >Maybe try having a one-pixel-wide white border around the existing >one-pixel-wide black border, and use semi-transparency rather than >xor'ing. You know, I've tried many coloring variants, including all kinds of borders, before I reluctantly set it to plain inversion. Reluctantly because most other apps use inversion too, and I hoped I could invent something smarter than most. Nope, it did not work. Any border immediately makes the handles look noisy (there's no AA) and overcomplex, and any color of their own damages the subconscious abstraction of the handles as something entirely different than the objects. Besides, it is well known in design that transparency and fancy colors only work starting from some minimum size; in too small objects they only give you annoying "dirt". Small things must use bold simple colors (or inversion) to be visible and usable. > I'd guess that semi-transparency would be more real-world-like >than xor'ing, and hence perhaps less distracting. Being real-world-like is a good goal when you are drawing a real-world-like picture. When you are creating an _interface_ to help you draw pictures, however, the goal is different and in some aspects even opposite. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.ms…

2 1