W dniu 23 października 2009 17:18 użytkownik Jon A. Cruz
> You are thinking of *your* intuition. There is roughly half the user
> population who's intuition is the *opposite* of yours.
You say that 50% of people prefer linking and 50% prefer embedding. I
am certain this is not true. Most people expect the image to stay in
place. When you send an email attachment, it is not a magical link to
the data on your computer. When you paste an image into a Word / ODT
file, it is not a link to that file on your hard disk. When you paste
SVG elements from another document, they do not magically become a
link to that second document.
> However... I don't think the "Therefore" actually quite matches. Among other
> issues, a drag-n-drop is actually a complex paste operation. So I think the
> code is doing a few things you don't expect.
Drag and drop is currently not related to pasting, because drag and
drop is implemented in src/interface.cpp, and pasting in
src/ui/clipboard.cpp. They don't use the same code path. In fact the
import code is simpler, because imported / dragged items are put into
a group. Not sure if that's what you meant.
> Also for the import case, embedding will break things for many, many users.
> We've looked at that a few times.
For who, and in what cases? You sometimes say that a proposed solution
will cause 'important issues for many users', but don't say what those
issues actually are.
> The good solution is to create a "media manager" that handles things like
> images, linked css files, ICC profile files, etc.
This would be great to have, along with UI improvements to enable
using common styles. The image links manager proposed in this thread
is a good start, and could be extended to Still, I think this is
orthogonal to what the defaults are.
> Things can then be worked
> out with the UI and perhaps a "Publish" menu/command that does things a bit
> more explicitly than "save as" or "export".
I think that "Publish" is a stupidity cloned from Corel Draw. Why
should saving a PDF be completely different from saving any other
file? Moreover the name is misleading: you are actually not
'publishing' anything in the sense of showing it to the outside world.
You are only saving a file. A better name is "save standalone
document" or something like this, but I don't see a difference between
this and Export.
And please be sure to file a bug/feature request at
In the end there will obviously always be cases where Inkscape is too
slow, but Inkscape could most definitely be faster in some cases. And
just locking/unlocking the layer should (from an intuitive standpoint)
NOT cause such a big pause.
Dave M G wrote:
> Thank you for responding.
>> I have long moaned that "Nodes mean slow" :( I have a fast machine and 2gigs
>> of RAM. It makes no difference. I think it's all the looping through those long
>> lists of nodes....
>> You are doomed. Unless you can simplify or chop-up your comic page into frames
>> and assemble them later in Gimp.
> Okay. While it's a little disappointing that there isn't a way to
> optimize the file for better performance, it's good to know that at
> least I'm not doing something wrong.
> I'll export the paths into a PNG and handle the colouring in Photoshop
> or GIMP. It means committing to rasterizing the images sooner in my
> process than I had hoped, but hey, life is full of compromises.
From: suv@...2204... [mailto:suv@...2204...] On Behalf Of ~suv
Sent: zondag 25 oktober 2009 21:35
To: Engelen, J.B.C. (Johan)
Subject: Re: [Inkscape-devel] [bug tracker] Guideslines for tags?
On 25/10/09 21:11, J.B.C.Engelen@...1578... wrote:
> From: Maximilian Albert [mailto:maximilian.albert@...1439...]
>> 2009/10/25 Pajarico <pajarico@...400...>:
>>> I started using the tag 'cli' for command line problems.
>> Wouldn't it be better to use a more descriptive name?
>> Frankly, if I hadn't read this email I'd have no clue what it is
>> supposed to mean.
> I agree with Max. Just write it out "command line", like we do with
> the other tags.
> (I read it as "clear interrupts" assembly ;)
'command-line' or 'commandline' - Launchpad doesn't allow spaces in
tags, and 'command' and 'line' don't make much sense as separate tags
I was thinking about starting on an extension repo, and have a
couple of questions.
Should this be hosted by the Inkscape project? If so, how do I go
about getting access? Or at least finding out what version of
php/python/mysql are available to set up a local test site?
If not, is anyone willing to pool resources for hosting? Or know of a
good FOSS-friendly place to host?
Any thoughts or opinions on server/language/db? I'm leaning toward
apache/php/mysql, but something like cherrypy/python/sqlite would be
well suited to this task as well.
I've tested all the various file export options under the Save As
command. Would the relavent experts for each type please review my
comments/questions below? All test were done with Fedora 9 Linux and
0.46+svn updated within the past couple of days. Thanks.
General comment: I am having trouble getting Uniconvertor to work from
within Inkscape. It won't process files with text (error message about
not finding correct font). Files without text produce SVG output
(Uniconvertor 1.1.4), independent of which file type is selected. Or
error message about not finding SVG file in /tmp (Uniconvertor 1.1.3). I
may have screwed something up but Uniconvertor does work when used via
the command line (as in "uniconv test.svg test.plt") to directly convert
SVG files to other types. Does anybody have it working from within
Inkscape under Linux?
.ai: Missing. Failed to load message in extension-errors.log (same error
for DXF and ESPI). Works in v0.46.
.dfx: Generic AutoCAD export failed to load (see .ai). Plotter version
updated. Question: what is the target if the "ROBO-Master output" option
is not checked?
.emf: Does this still only work on Windows? Uses Uniconvertor.
.eps: This is using the same export dialog as PS. Is this appropriate
given that the bounding box is handled differently? Speaking of which,
while the specifications do say the bounding box should be the smallest
rectangle that fully encloses the drawing, it is a common practice (and
very useful in scientific work) to define the box to be bigger than the
drawing. In reading the specification, it seems to me, that they were
more concerned that the bounding box takes into account stroke width,
etc. than in prohibiting bounding boxes larger than the drawing size. I
think it should be left up to the user to decide this.
In the past "Canvas" has been used to refer to the entire drawing area
while "Page" has been used to refer to the SVG specified drawing area.
The dialogs and command line options should use "Page" wherever "Canvas"
.fx I see small bugs in gradients and displaying a pattern.
.hpgl I see bugs in object transformations. Uniconvertor as of 1.1.4
also generates .hpgl files. Uniconvertor doesn't handle Inkscape
.odg. Small translation problems.
.pdf. Generally OK. Bug in patterns made from a group of objects drawn
off the page. Export dialog almost the same as for EPS and PS but small
differences in wording and in order of options. Should match with EPS
and PS dialog.
.plt Uses Uniconvertor. Tool tip etc. state it is AutoCAD plot file...
but this is really, as far as I can tell, just HPGL.
.png Duplicates "Export Bitmap" menu entry but without handling Filtered
.pov Broken in v0.47. Extra lines are added to object descriptions.
Works in v0.46 (some paths missing).
.ps See EPS and PDF comments.
.sk1 Uses Uniconvertor.
.svgz Broken in v0.47. Works in v0.46
.tex PSTricks OK, PSFrag needs work-around due to Cairo font subsetting.
.wmf Uses Uniconvertor.
.xaml Objects translated wrong (could be xaml input problem).
I think it is time to start the nagging to get the release notes
complete. Here are the things I have noticed missing:
1. Undocumented Live Path Effects
2. Undocumented Extensions
Modify Path -> Interpolate Attribute in a Group
Generate from Path -> Motion
Generate from Path -> Scatter
3. New location of preferences.xml etc.
4. Undocumented Import/Export
5. Changes to Tools
Sketch mode for Pencil Tool needs expansion.
Missing change to Pencil Tool and Pen Tool for dots.
6. SVG Test Suite Compliance
Fill out skeleton.
7. Extended input device configuration
Does it work?
8. Document Properties Dialog
What is purpose of Script tab?
I'm testing the latest 0.47 pre4 on OS X - 10.5.8 at work and perspective
works just fine.
But at home i have OS X - 10.6.1 and doing perspective fails and gives this
The fantastic lxml wrapper for libxml2 is required by inkex.py and therefore
this extension. Please download and install the latest version from
http://cheeseshop.python.org/pypi/lxml/, or install it through your package
manager by a command like: sudo apt-get install python-lxml
Is something just not finished in the 0.47 or is it something changed in
View this message in context: http://www.nabble.com/Inkscape-0.47-pre-4%2C-OS-X-10.6.1%2C-The-fantastic...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
I have a client who needs a later version of lxml to be picked up by
Inkscape* on OS X. Unfortunately, I do not have access to OS X, so
I'm not sure how to best acheive this - any advice would be most
welcome. I'm not sure what version of OS X, but I'm guessing the
procedure will be somewhat similar on all of them...
* I thought the target system was win32, but we crossed wires
somewhere. If I'd known about bug #448285 in the first place, I would
have written the extension differently from the start - but as it
stands I don't think that I have enough time. His deadline
On Mon, Oct 19, 2009 at 11:21 PM, ~suv <suv-sf@...58...> wrote:
> Just tested and put the lxml and numpy for python 2.5 that I had
> compiled with MacPorts into the 0.47pre4 bundle and Inkscape loads them
> fine and reports lxml version 2.2.2 :)
> i.e. I could zip them up and add the zip to your bug report for you or
> him to download _if_ your client runs 10.5.8 (i386) with python 2.5 or
> python 2.6 installed. He just has to unzip them and copy the folders
> into the bundle, no need to build them on his machine. If he still uses
> Tiger OS X 10.4.x or has a PPC processor then I can't help.
> I haven't built a DMG before - so I would prefer a simple zip...
Back on list - just for posterity :)
That is good news - I'm still waiting to hear back on his OS X version
and arch. I'll report back once I have some more info either way.
Thanks for the assistance.
Thanks to all who confirmed or added their translation (some translations still need to be confirmed!). Wiki page updated (http://wiki.inkscape.org/wiki/index.php/AboutScreenTranslation).
Johan is very busy at the moment, thus I've started to translate the screens by myself.
I've tried Excellentia, but due to a very limited accents support, I've finally switched to Harabara Hand
(http://www.dafont.com/harabarahand.font). The only drawback is that it
doesn't support Cyrillic and other Unicode characters.
Since I haven't found a nice script Cyrillic font, the
Russian screen uses URW Chancery L (a default Ubuntu font). It's not a
script font, but it looks better than a Times or Arial in this context.
The translated screens are now (revision 22547) br, fr, it, nl, pt_BR, and ru.
Could you please take a look at the screens and tell me what you think of the chosen fonts before I continue?
Johan, do you want to keep your original untouched, or replace the "draw freely" font by Harabara Hand (or another script font)?