- Inkscape Devel - Inkscape Mailman

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

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. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

4 3

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

27 Feb '04

>who would not want to paste in place? Most people use copy/paste for moving objects to other documents or to other parts of a document. Therefore it makes perfect sense to paste into where you are working now, instead of the old place which may well be invisible in your current view area. If you want to duplicate an object without moving it, you don't need copy/paste; use simply Duplicate (Ctrl+D). 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? >Is there a way to have ctrl+v do >paste in place instead of just paste? this already pissed me off, when I >was using adobe indesign, but I was able to quickly change that. How do >I do so in inkscape? There's no easy way to do this until we make all shortcuts configurable (it's in our plans). For now you can edit src/shortcuts.cpp replacing sp_shortcut_set (SP_SHORTCUT_CONTROL_MASK | GDK_v, SP_VERB_EDIT_PASTE, true); sp_shortcut_set (SP_SHORTCUT_CONTROL_MASK | GDK_V, SP_VERB_EDIT_PASTE, false); sp_shortcut_set (SP_SHORTCUT_CONTROL_MASK | SP_SHORTCUT_ALT_MASK | GDK_v, SP_VERB_EDIT_PASTE_IN_PLACE, true); sp_shortcut_set (SP_SHORTCUT_CONTROL_MASK | SP_SHORTCUT_ALT_MASK | GDK_V, SP_VERB_EDIT_PASTE_IN_PLACE, false); with sp_shortcut_set (SP_SHORTCUT_CONTROL_MASK | GDK_v, SP_VERB_EDIT_PASTE_IN_PLACE, true); sp_shortcut_set (SP_SHORTCUT_CONTROL_MASK | GDK_V, SP_VERB_EDIT_PASTE_IN_PLACE, false); sp_shortcut_set (SP_SHORTCUT_CONTROL_MASK | SP_SHORTCUT_ALT_MASK | GDK_v, SP_VERB_EDIT_PASTE, true); sp_shortcut_set (SP_SHORTCUT_CONTROL_MASK | SP_SHORTCUT_ALT_MASK | GDK_V, SP_VERB_EDIT_PASTE, false); and recompile. _________________________________________________________________ Help STOP 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…

1 0

paste: ctrl+v
by David Christian Berg 27 Feb '04

27 Feb '04

who would not want to paste in place? Is there a way to have ctrl+v do paste in place instead of just paste? this already pissed me off, when I was using adobe indesign, but I was able to quickly change that. How do I do so in inkscape? David

1 0

xft font fixes
by bulia byak 27 Feb '04

27 Feb '04

Today I looked into how Inkscape finds and presents fonts (using Xft, i.e. this only affects Linux). Lots of problems are now fixed. 1. For some reason, Inkscape ignored all fonts from *.pfa files, commenting thus: /* fixme: This is silly and evil */ /* But Freetype just does not load pfa reliably (Lauris) */ /* Changed to exclude pfa, better for OSX */ In my tests, pfa fonts are loaded just as well as any other fonts. So I restored the pfa loading capability. Now I need someone else to confirm that it works with pfa fonts. This may fix bug 894947. 2. Much worse, when parsing a font, Inkscape (that is, Sodipodi, because this part of the code did not change from Sodipodi times) only pays attention to weight and slant - and nothing else. As a result, font faces within a family that differ in some other parameters (condensed, outline, small caps etc) were simply ignored, not used and not shown. Until today, Inkscape only loaded 173 font faces on my system; after I fixed this and the pfa loading, it shows 202! This will likely fix bug 904962. 3. The names for faces within a family were constructed by Inkscape from the numeric weight and slant parameters. As a result, all fonts were shown in the list as "Normal", "Italic", etc., even when the fonts used different style names (Regular, Book, Slanted etc). Now it remembers and uses for display the exact style name of the font as returned by Xft. 4. When sorting full font names into families, a rather stupid algorithm was used which unreliably compared font names with family names. As a result, fonts sometimes ended up in wrong families. This is now fixed, each font remembers its exact full name and family name as reported by Xft. 5. Very annoyingly, the list of styles in the Text dialog was not sorted. Now it is sorted so that Regular or Roman always comes first, then Italic, Bold, Bold Italic. TODO: This is only tested on Linux. I may well have broken something on Windows. This also requires additional testing (and likely coding) to accommodate non-ASCII font names and style names. _________________________________________________________________ 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 3

[Fwd: Re: [Sodipodi-list] Re: Reply To: Sodipodi / *nkscape...]
by Jonathan Phillips 27 Feb '04

27 Feb '04

This is an unfortunate attitude. I disagree thoroughly with many points of contention in the following forward. I do think the best course of action towards this type of negative emotional criticism is to blow past it and focus on the goals (ie, our roadmap--prove the critics wrong). My initial response was to point by point discuss reply to this on the sodi-list, but I do not agree with that philosophy, as I feel that Inkscape is moving in the totally proper way. The reason we forked is because the codebase was being held up and communication was being routed (basically) through one person's decision-making. While the codebase might be open source, that style of management sounds similar to many top-down closed source projects, and thank God that both codebases are GPL'ed. FYI Jon -----Forwarded Message----- From: Tobias Jakobs <tobias.jakobs@...128...> To: Sodipodi <sodipodi-list(a)lists.sourceforge.net> Subject: Re: [Sodipodi-list] Re: Reply To: Sodipodi / *nkscape... Date: Fri, 27 Feb 2004 21:48:51 +0100 Am Do, den 26.02.2004 schrieb Lauris Kaplinski um 22:44: > Hello! > > It was probably complicated story, but I know little about > the actual reasoning among the *scape guys. But certain aspects > of their immediate behaviour were unacceptable in my opinion. > - Immediately after creating fork, instead of keeping low > profile for a while, they started massive advertizing > (and vapourware) campaign to draw the attention away from > sodipodi to their project. Sodipodi had progressed slowly > to the state, where it started to draw more and more > attention. I think that was normal PR and in every News was the sentence "Inkscape is a Sodipodi fork." And that is even PR for Sodipodi. This was not against Sodipodi. > I had personally hoped to start making money > working on it, How? > that is now very much hopeless, as I have > no resources to compete. They will slow down, belief me. > - The for was from the start not so much about technical > disagreements, No technical disagreements? C++ vs. C SVG vs. perhaps something else GTK vs. "gtk is to slow perhaps I will something new" > but about personal egos. Other than small > cosmetic changes, *scape is targetting exactly the same > audience, development and usage philosophy than sodipodi. > So this makes quite clear, why they chose to do total > rename, instead of working on 'sodipodi on steroids' or > whatever similar thing. > - The main initiator of fork was at the same time working > for major OSS promoting organization (OSDL). This gave > him instant advantage by having more connections and > resources to promote the fork. I also find it quite > inappropriate for an employee of OSS promoting organization > to 'steal' other people's project. > You haven't lost anything. And it is there right to fork, even if it is just because they don't like the maintainer. > In brief - thay take my (plus several other contributors) > 4-year work, branded it as their own, and started 'selling' > it as their own. If that is, how free software developments > turns out (the ones with more advertizing power always screw > independent developers), I see little reason, why we should > case about OSS more than from properietary ways. > Advertising is for OSS as important as for proprietary software and it always was. Think about Linux vs. BSD ... > Sorry for ranting... :-( > I can understand you. > > Do you have any plans to arrange Sodipodi's GUI to > > something similar to *nkscape's ??? > > Currently, this is *nkscapes only 'Real' advantage over > > Sodipodi ( as it improves the workflow considerably ). > > I do not know, what you exactly mean by rearranging sodipodi > GUI. The medium-term target for us is GIMP-2 GUI with detachable, > draggable, dockable toolboxes and dialogs (althoguh without > per-window menubar probably). The Incsape GUI is really bad, you need much more clicks and mouse moves and if you use more than one document it is even worse. I really love the GIMP2 GUI. MfG Tobias

1 0