June 2004 - Inkscape Devel - Inkscape Mailman

Thoughts on units
by Peter Moulder 16 Jun '04

16 Jun '04

I'm going home now; here are some initial notes on choice of units and difficulties converting between inches and px. pjrm. Let us assume that in the produced SVG, there are no units other than px, except for the attributes of the <svg> element (width, height). This is inkscape's usual behaviour. Before an SVG agent looks at an SVG document, it calculates a px/in value from its environment, e.g. by consulting the X server or a printer profile for a dpi value, and choosing an appropriate px/in value that would have an integer number of device dots per px. The px/in value should vary according to expected viewing distance: around 120px/in for printers and around 90px/in for monitors. Because there should be an integral number of device dots per px, the px/in value may vary more than this for low-resolution devices, like 72px/in for a 72dpi monitor or printer, or 144px/in for a 144dpi printer. When Inkscape offers to convert between px and inches, it currently assumes a fixed 90px/in. We could make this configurable for purposes of rendering and conversions, which helps if you're drawing for your own printer or screen, but doesn't help much if the document is to be rendered on many different monitors and printers: inkscape's conversions between px and inches can be out by sqrt(2) or more if the document is to be rendered both at 72px/in and at 144px/in (to use the examples of the previous paragraph). If a document's <svg> element has a viewBox attribute and width & height attributes specified in real-world units (mm/in/pt/cm/pc), then we can say that the document's primary unit is real-world units. If the viewer has accurate dpi information, then the document can control lengths in real-world units (mm, inches), but cannot accurately control lengths in px. If a document's <svg> element lacks a viewBox attribute or its width & height attributes are missing or specified in px, then we can say that the document's primary unit is px: the document can control lengths in px, but cannot accurately control lengths in real-world units like mm or inches. An interesting possibility is to use em for the document's primary unit. Depending on how the initial size of an em is determined for svg, this might be good for people needing large fonts. Varying needs: Eyesight (need for large fonts); actual device resolution; actual viewing distance; X server dpi setting. Atypical viewing distances: - Bill-boards. - Wall projectors. - Casual display for crowds, e.g. in cinema entrance hall, airport lounge, train station. For people with poor eyesight that need larger fonts, neither real-world distances (mm) nor angular measures (reference px) are suitable. In the case of a wall projector used for a typical presentation, true real-world lengths (mm on wall) are irrelevant. However, in this case the X server is typically misinformed about the device resolution: it will probably assume about 100dpi. Documents designed for viewing on a normal desktop monitor that use mm as the primary document unit will look too small. This case is similar to the poor-eyesight case (see below). In some cases, it is practical for someone to apply custom scaling. In the wall-projected presentation case, the presenter may be able to import the SVG document into a presentation document and apply scaling. If the scaling is tweaked per presentation (differing projector or computer or X server settings) then any primary document unit can work fine. Similarly for the billboard case. [Proportion of "page" (screen) may be a meaningful measure for this case, but that's complicated by non-squareness of page dimensions. The user could set the page width to be 100 of an arbitrarily-chosen unit (whether mm or px) and consider them as percentages.] Users needing larger fonts (including the wall-projected presentation case) may configure their X server to assume a high dpi for normal X font rendering purposes, but this would be defeated by the integerization aspect of CSS px. I'd guess that most viewers would use 1 dot/px even if the X server claimed 180dpi. However, having mm as the primary document unit would result in scaling as desired. A "reference px" is 1/90" at 28" viewing distance (typical screen distance), or 1/120" at 21" viewing distance (typical printed page distance) (http://www.w3.org/TR/REC-CSS2/syndata.html#length-units). More generally, the reference px is 1/2520 of the viewing distance. (2520px/viewdist = 90px/in * 28in/viewdist = 120px/in * 21in/viewdist.) The actual length of a px for a given viewing distance should be an integer number of device dots. E.g. on a 72dpi monitor, a px is 1/72". If the viewing distance is still 28" then a px is 125% of the size of a reference px: 2016px/viewdist. A monitor from 1994 may be flickery at 1024x768, so one would usually use 800x600, giving about 60dpi. If 28" viewing distance then a mere 1700px/viewdist, but one might sometimes compensate for the small dpi by having a larger viewing distance, making the dots look smaller (more px/viewdist). If the target devices have little disadvantage in "fractional number of dots" (e.g. printer >= (300dpi * 20in viewing distance), or greyscale screen >= (100dpi * 26in viewing distance)), then ideally use a unit like px but without the integerization. Given that there is no such unit in SVG: If we can assume a fairly fixed viewing distance (e.g. consider just on-screen or just printed page or just billboard), then use mm. If the target output devices have fairly high dpi (so high dots per px), then the integerization doesn't have much effect, so px is a good choice. If there isn't much "body-sized" or small text, or other fine detail (such as in icons), then scaling doesn't matter much. Monitors with low dpi often also have a small viewing area, which suggests that mm is better than px. Otherwise, use px.

1 0

Arc in SVG exported by Dia makes wrong turn in Inkscape
by Colin Marquardt 15 Jun '04

15 Jun '04

Hi, I have a bubble diagram (circles connected with arcs basically) that I export as SVG with dia 0.93. When opening this drawing in Inkscape (CVS from May 27th), almost everything is fine, except for one arc which still has the same start and end node coordinates, but opens in the wrong direction and is huge. I guess the tangents at the end nodes are also correct, just the orientation of the arc is not. Is this a known problem, or should I submit a testcase for this? Cheers, Colin

3 4

off-topic, but maybe related: ghostricpt got broken after installing inkscape-20040610
by Peter Linnell 14 Jun '04

14 Jun '04

> Message: 13 > From: Artemio <theman@...283...> > To: inkscape-devel(a)lists.sourceforge.net > Date: Sun, 13 Jun 2004 13:00:46 +0300 > Subject: [Inkscape-devel] off-topic, but maybe related: ghostricpt got broken after installing inkscape-20040610 > > Hello everybody! > > This may be off-topic, but maybe not. I didn't do anything to my system except > for installing inkscape-20040610 yesterday. > > I have been using my system (Mandrake Linux 10.0) for three months: viewing > PS/PDF files, creating PS/PDF files - all with ESP Ghostcript 7.07 (that one > with CUPS). But yesterday, suddenly, GS became broken. > > So, everytime I try to view a PS or PDF file with KGhostView, Ghostview or any > other viewer, and everytime I try to print to PS or PDF, I get an error > message box from these applications, they show a gs command line and an error > message: "Unrecoverable error: syntaxerror in token Operand stack: > --nostringval-- --nostringval-- Zmachine sRB --nostringval--" > > I don't have any GS_* variables defined except fot GS_LIB=/home/artemio.fonts > > The weird thing is that when I say "gs" in the command line, I instantly get > this: > > ESP Ghostscript 7.07 (2003-11-19) > Copyright 2003 artofcode LLC and Easy Software Products, all rights reserved. > This software comes with NO WARRANTY: see the file PUBLIC for details. > Unrecoverable error: syntaxerror in token > Operand stack: > --nostringval-- --nostringval-- Zmachine sRB --nostringval-- > > On my system, /usr/bin/gs is symlinked to /usr/bin/gs-common, and gs-common is > an ELF executable, not a shell wrapper that adds some extra options. > > > Please excuse me if this is off-topic here, but I just don't know what to > do... > > > Artemio. --nostringval-- --nostringval-- Zmachine sRB --nostringval-- <<--- GS is complaining it can't find that font 1) something you are trying to print has that font embedded in the postscript stream or 2) your GS fontmaps are messed up. 3) your fontconfig cache is stale Possible fixes: 1) as root fc-cache -fv - this refreshes the fontconfig cache 2) remove any and all freefont* rpms - Some of the ones shipped by Mandrake have some really busted fonts which have caused issues for Scribus. 3. Reinstall all the Ghostscript packages so the default fontmaps are restored. Drop into #scribus if you need more help. Cheers, Peter

1 0

Re: [Inkscape-devel] valgrind complaint with the new text stuff
by bulia byak 14 Jun '04

14 Jun '04

>Perhaps this is because pango_font_description_set_size () is not being >called on the PangoFontDescription which is created at line 340? I need not to. That descr is passed further to Face(descr) which sets size in line 280. _________________________________________________________________ MSN Premium helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

1 0

valgrind complaint with the new text stuff
by Carl Hetherington 14 Jun '04

14 Jun '04

Hi, valgrind observes some problems, examples of which are: ==27369== Invalid read of size 2 ==27369== at 0x40AA72EF: pango_font_description_equal (in /usr/lib/libpango-1.0.so.0.200.1) ==27369== by 0x818C9F8: font_factory::Face(_PangoFontDescription*, bool) (libnrtype/FontFactory.h:37) ==27369== by 0x818CCB3: font_factory::Face(char const*, NRTypePosDef) (libnrtype/FontFactory.cpp:388) ==27369== by 0x80BD1ED: sp_string_calculate_dimensions(SPString*) (sp-text.cpp:831) ==27369== Address 0x45CE4F14 is not stack'd, malloc'd or free'd ==27369== ==27369== Invalid read of size 2 ==27369== at 0x40AA72EF: pango_font_description_equal (in /usr/lib/libpango-1.0.so.0.200.1) ==27369== by 0x818D443: __gnu_cxx::hashtable<std::pair<_PangoFontDescription* const, font_instance*>, _PangoFontDescription*, font_descr$==27369== by 0x818CAF8: font_factory::Face(_PangoFontDescription*, bool) (/usr/include/c++/3.2.2/bits/stl_pair.h:84) ==27369== by 0x818CCB3: font_factory::Face(char const*, NRTypePosDef) (libnrtype/FontFactory.cpp:388) ==27369== Address 0x45CE4F14 is not stack'd, malloc'd or free'd ==27369== ==27369== Invalid read of size 2 ==27369== at 0x40AA72EF: pango_font_description_equal (in /usr/lib/libpango-1.0.so.0.200.1) ==27369== by 0x818C9F8: font_factory::Face(_PangoFontDescription*, bool) (libnrtype/FontFactory.h:37) ==27369== by 0x818CCB3: font_factory::Face(char const*, NRTypePosDef) (libnrtype/FontFactory.cpp:388) ==27369== by 0x80BDA9A: sp_string_set_shape(SPString*, SPLayoutData*, NR::Point&, int*) (sp-text.cpp:968) ==27369== Address 0x45CE4F14 is not stack'd, malloc'd or free'd In case that's any use to anybody ... Cheers Carl

1 1

de.po update for inkscape upcoming
by Colin Marquardt 14 Jun '04

14 Jun '04

Hi, in order to avoid duplicated work... this is to announce that I will submit an update to the de.po that is in CVS in a few days - I have posted it on the gnome-de mailing list for review now. I did not have the time to translate everything, but it's an update nevertheless. I haven't checked (had a very poor connection, barely enough to the get the po file), but maybe it would be worth to msgmerge the po files from Sodipodi with the ones from Inkscape from time to time? Cheers, Colin

2 1

Fred / someone please check a commit
by Carl Hetherington 14 Jun '04

14 Jun '04

Hi, I just committed the following patch: Index: src/libnrtype/TextWrapper.cpp =================================================================== RCS file: /cvsroot/inkscape/inkscape/src/libnrtype/TextWrapper.cpp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- src/libnrtype/TextWrapper.cpp 14 Jun 2004 14:44:04 -0000 1.2 +++ src/libnrtype/TextWrapper.cpp 14 Jun 2004 23:05:45 -0000 1.3 @@ -393,7 +393,7 @@ int last_w_st=-1; int last_s_st=-1; int last_p_st=0; - for (int i=0;i<=nAttr;i++) { + for (int i=0;i<nAttr;i++) { text_boundary nbs; text_boundary nbe; nbs.uni_pos=i; Could people just check that they agree with it? Thanks Carl

1 0

Re: Inkscape-devel digest, Vol 1 #444 - 14 msgs
by Peter Linnell 14 Jun '04

14 Jun '04

> 8. Installing Inkscape on a Win machine (David Christian Berg) > Message: 8 > From: David Christian Berg <david.berg@...240...> > Reply-To: david@...139... > To: inkscape-devel(a)lists.sourceforge.net > Organization: SIP Solutions > Date: Fri, 11 Jun 2004 15:37:17 +0200 > Subject: [Inkscape-devel] Installing Inkscape on a Win machine > > Hi guys, > > since I'm working with Linux, I'll never have to personally, but > inkscape has become my favorite graphics tool, and I need to share files > with win users. Now since svg isn't supported that much, I thought, the > easiest solution might be to just have the win users install inkscape... > how hard is this? I mean including installing gtk. I hope this is real > simple and you can point me at some howto. The current packaging works great IMO: a. download b. unzip > > Also I wonder if there'll be work done on the ps export soon. Though I > really am looking forward to pangoisation being finished, I really need > a proper export of transparency for ps, to make pdfs for sharing, > instead of pngs, since pngs are huge, for A3 or A4 posters since I need > at least 300 dpi. > > Any chances, I will see something like that soon? > > > David >PS: The Scribus import filter isn't good enough for my posters... so >using Scribus for export is ruled out. Have you updated to Scribus 1.1.7, which has a bunch of new gradient support ? The other variable is the version of Ghostscript installed. Using a 8.1x version has better results overall. Text handling on SVG import is the next issue to tackle, but IMO most text work can be done in Scribus more effectively - not a knock on Inkscape, it is just that SVG and PS/PDF text models are a bit different and easier to translate into reliable PDF via Scribus. I wrote a howto for installing parallel GS's, so you do not need to remove the existing patched GS which most distros supply: http://ahnews.music.salford.ac.uk/scribus/documentation/gsadv.html I hate to sound like a broken record, but exporting transparency in PS is not a trivial task. In pre-press, I would think it is safer and really much better to use PDF 1.4 for handling transparency downstream with printers etc. PDF 1.4 spec supports this capably. Moreover, even if Inkscape were to do this (export transparency) in PS, few printers or print setups on typical Linux distros can fully support advanced PS3 printing. I know - I've tested with Suse 9.x and Fedora with a Fiery PS3/PDF1.4 RIP. It took some tweaking to get this working properly. I basically rebuilt all the CUPS rpms to enable PS3, which is turned off by default. Otherwise, Inkscape would need to add a flattener to the exported PS - again not trivial. Peter

1 0

ill2svg.pl change
by Bryce Harrington 14 Jun '04

14 Jun '04

ill2svg.pl now auto-detects the file format (Unix, Mac, or DOS) and performs line ending conversion appropriately. This makes the -l cmdline option unnecessary, and thus it has been removed. Let me know if this causes any compatibility issues. Bryce

2 1

RE: [Inkscape-devel] Report on Bugs
by bulia byak 14 Jun '04

14 Jun '04

>Bug 852976 is reported a LOT, there's probably 3-4 other bug reports >that describe basically the same problem, that I left at lower priority. >We've looked at it before and it seems to be a Gtk-on-Windows issue so >there might not be much we can do about it. It would be nice if someone >could figure out if there's a work-around of some sort for Windows that >would stop the crashing, even if it required disabling a feature on >Windows (e.g. autoscrolling). Autoscrolling is irrelevant. GTK just drops events when mouse is outside a window. I've spent a lot of time on this and I honestly don't know what to do. Someone with fresh energy must attack it. The most annoying thing is that Sodi does not suffer this malaise (reportedly). _________________________________________________________________ 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…

1 0