new .48 XAML output not compatible with silverlight, PathFigureCollection not supported in silverligth 5
by Damian Hallbauer
Hello,
Thanks for your continued development on Inkscape. Due to all the format
wars this the best and only tool i can use for my self-funded Silverlight
game.
But I'm having a problem. We have been stuck using version .47 and it was
crashing allot randomly, but the xaml worked, in WPF and silverlight.
finally got .48 to work, it is stable, but i get a problem, its now using
PathFigureCollection for any simple path.
here is the issue i am stuck with now.
http://stackoverflow.com/questions/11331549/why-does-this-xaml-path-crash...
. MSIE wont draw it.
Could you please revert so that the XAML does without the Figures= ? Or set
it as an option if you are taking it somewhere needed?. So far i see only
one object in the collection anyways.
I just downloaded the latest daily build from Skydrive and still see the
Figures..
This may affect RT, phone 8 and other developers.
Another smaller issues i have:
-thinner line weight on paths do not show in xaml. ( this worked in
inkscape .47)
i work around it by scaling 10x more on my drawing, then import at
0.001 scale.
-groups do not show in xaml( this is still broken but i just ungroup for
now)
we only use simple paths, layers, strokes, and sometimes groups.
if my game makes any money after this 4+ years development i will donate.
Yours,
Damian Hallbauer
10 years, 1 month
preview in filter extension
by TimeWaster
hi list,
i am trying to program a python filter extension and i need to know if
the script is called for preview or for the live run.
i already found out that the script is called when the preview checkbox
is checked and when the apply button is pressed, but i found no
differences in the data delivered to the script when called.
in the c++ code both calls are different, but from the python side they
seem to have the same effect.
are there any differences? or is there any other way to determine what
was clicked?
thanks in advance,
TimeWaster
--
Save a printer manufacturer. Print this e-mail unless it's really
necessary not to do so.
10 years, 1 month
Extrangle [Y] coordinate in a Geom:Point generated with controlPontPosition::selectAll
by Jabiertxo Arraiza Cenoz
Hi to all.
Posted in IRC, no rsolve. New attemt, maybe this is a better plaze for
this type of cuestions.
Im attemting to fit identical, the position of 2 Geom:Points, one
generated by Inkscape::UI::controlPontPosition::allNodes() and a cast to
Inkscape::UI::Node->position() and the other with
first_segment()->initialPoint().
The values need to be the same but one return 154.13750999999999,
406.75175261718755 and the other 154.13750999999999, 645.61042999999995.
Whith other node/segment the values are -74.927954, 664.71799261718752
and -74.927954, 387.64418999999998.
The value with initialPont is similar -rouded- than in the SVG. I test
to pass to the other desktop->w2d,desktop->d2w, and normaliza(), with no
luke.
What im doing bad?
By, Jabier.
10 years, 1 month
Compiling new files
by Arshdeep Singh
Hi people,
If I want to add custom .cpp and .h files to the make list, how can I
accomplish that ?
--
demicoder
10 years, 1 month
tablet input is laggy for Windows x64
by Yale Zhang
Inkscape developers,
I'm using a custom Windows x64 Inkscape build and I'm getting huge lags
(1/2 second or more) when drawing with my Wacom Intuos 5. Rather than
submit a bug report and waiting, I want to debug and fix it, if possible,
myself.
Can someone give me a clue how to approach this? I was thinking of
recording time stamps for input events in the event handler functions (e.g.
sp_dyna_draw_context_root_handler() ) but if the input event handler isn't
the bottleneck, I could measure time stamps of when the strokes show up on
the screen, but in which function would I find that? Also, I don't think
the processor is a bottleneck because I looked at the CPU usage when
rapidly scribbling and it only uses 1/2 the throughput of 1 core.
Also, is anyone out there interested in Inkscape for Windows x64? I know
the extra memory available doesn't help much, but believe that there should
be a speed boost from the extra 8 registers and SSE2. If there is demand,
are there any build issues that I can help with? I think I read from
previous posts that the main work was to switch to MingW64. I'm currently
cross compiling Inkscape on a Linux host.
Yale
10 years, 1 month
Windows 16-bit colordepth memleak
by Johan Engelen
Hi all,
A colleague today found Inkscape later than 0.48.2 unusable because
of a huge memleak. He was using it in 16-bit (remote desktop). We found
that on Windows 7, Inkscape 0.48.4 and trunk are unusable because of
very rapidly increasing memory usage it quits because of no more
available memory.
Steps to reproduce:
1. set Windows color-depth to 16-bit
2. start Inkscape
3. zoom in and out repeatedly (mousewheel)
4. watch the used memory increase very rapidly in the task manager
Might be easy to fix this, perhaps some of the blitting/display code
assumes a 32-bit buffer?
I've added it to the know issues for 0.48.4 and 0.49.
(I remember that earlier versions of Inkscape would not even start when
using 16-bit colordepth.)
Thanks for looking into it!
Cheers,
Johan
10 years, 1 month
Right to left language support, is this intended or a bug?
by mathog
Here is a test file:
http://saf.bio.caltech.edu/pub/pickup/hebrew_decorations1.svg
It starts with two Hebrew sentences (R->L) and ends with the English
word "overline"
(L->R). It is all overlined (text-decoration.) So the text is
supposed to look
like this:
__________________
--3--><--2--<--1--
The first Hebrew sentence is longer and the second one has two words of
three
characters each. (No browser I tried rendered this correctly, hence
the long verbal
description.)
Anyway, when an attempt was made to print this to an EMF file this is
what was observed:
1. Each Hebrew character was sent as its own string.
2. In "style" both "direction" and "block_progression" computed values
were set to 0.
3. The one English word was sent as a string (not character by
character). Again,
the direction and block_progression were set to 0.
Naively for this sentence I expected to see two calls to
PrintEmf::text(), the first with all
of the Hebrew and text direction nonzero, and the second all English
and direction zero.
Only the second part of that was correct. Before I try to "fix" it - is
the current character by
character behavior for R->L text intentional? (Not having tried to fix
it yet,
it could well be that this is a side effect of some of my changes.)
On a related note elsewhere, for instance, when rendering text to the
screen,
Inkscape leaves mixed L->R,R->L tspans in one piece - and then does
some very strange things when one tries to navigate with the arrow keys
within them to edit
the text. Would it perhaps not be better to break up all mixed
direction tspans that hit TNG compute
into 2 or more tspans, each of which is either all R->L or all L->R
characters, and for good measure,
has the direction="rtl" and "ltr" tags set to match? Doing it the
current way all sorts of other pieces
of Inkscape have to know about bidirectional text. Without the tags
being set other code cannot in general
determine the tspan direction quickly - put 20 leading and trailing
spaces around the core text, and the direction
is not determined until something other than a space is encountered.
Reduce all such tspans to homogeneous pieces
in the TNG compute code and the rest of inkscape only needs to know how
to handle the extra direction information
for each tspan - which is much simpler to deal with than bidirectional
text.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
10 years, 1 month
Problem with scale/rotate as root
by Jabiertxo Arraiza Cenoz
Hi.
In a debian testing box amd64, i have a problem running inkscape as root
user, when select 2 or more nodes of a path, no handles to
scale/rotate/skew show.
Is the correct behabiour?
By.
10 years, 2 months
