Obscure kerning issue
by mathog
My code to reassemble text from pieces written to EMF files is working
great now except for one nagging problem, which
only shows up in a few special cases involving manually kerned text.
Consider these three sequences:
1. <period><space><A>(hkern + 3.75)<vertical bar>
2. <period><A>(hkern + 3.75)<vertical bar>
3. <period><space><A><vertical bar>
The individual pieces written to the EMF (not reassembled) map exactly
onto the originals, so there is no problem
in the output coordinates. However, when reassembled into a single
<text><tspan> complex (2) and (3) are still OK, but
(1) is off, with the vertical bar offset leftwards towards the "A", yet
the ". A" is exactly where it should be.
I have tracked the problem down to the extent that I know Inkscape's
display code is calculating
the width of ". A" differently, when manual kerning is present, than
just the sum of the advances of those characters.
(Logic: the complex looks like
<text><tspan></tspan><tspan</tspan><text> and the second tspan pair has
a dx value calculated by subtracting from the start position of the
fragment [which is correct] the start position of the previous fragment
[which is also correct] plus the width of the previous fragment [which
must therefore not be correct]. Changing dx to match the original
kerning fixes the problem - also consistent with the calculated width
not matching that from Freetype2.) Inkscape seems not to be using
Freetype Kerning corrections of this type:
FT_Get_Kerning( fsp->face,
prev_glyph_index,
glyph_index,
kern_mode,
&akerning )
I tried adding that, and while there was a correction for " A", it only
half fixed the problem. Besides, I could not
find a call to FT_Get_Kerning anywhere in the source. (It might be
called indirectly by some other library.)
This was all done on one machine, so it isn't a case of mismatched
fonts between machines.
Anybody have a thought on what Inkscape might be doing to come up with
a different string width in this particular instance?
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
10 years, 2 months
tspan Text Starts
by Martin Owens
hey guys,
I'm developing an extension to manage translations (which I do via
launchpad and xml2po) but I'm having trouble with tspans.
The problem seems to be that inkscape saves multiple values for the x
attribute for some (not all) tspan sections. Specifying the letter
placements is death to translations as the number and size of letters is
guaranteed to be different.
Is there any api way to strip out these bumbling attributes or better
have them not appear in the first place?
Thanks for your time.
Best Regards, Martin Owens
10 years, 2 months
Updated code in SpiroLIve
by Jabiertxo Arraiza Cenoz
SpiroLive branch update.
Fix some redraws problems.
Full comented SpiroLive code, in spanish sorry ¿Any tranlator?
Regression to original codebase "sp_pen_context_set_polyline_mode"
overloading whith a new function "sp_pen_context_set_mode"
I want to mark for include in codebase, feedback are welcome.
Hi, Jabier.
10 years, 2 months
Tiling tool
by Tom Lechner
I was reading that Veronika Irvine's Tiling Tool Summmer of Code project
was successful, which is quite exciting.
Can this be downloaded somewhere? I can't seem to find reference to it..
-Tom
10 years, 2 months
Sorin based SpiroLive behabiours
by Jabiertxo Arraiza Cenoz
Translated by google
-------------------------------------------------- --------------------
Hi.
I just upgraded to SpiroLive branch as directed by Sorin, with which I
agree. Containing historical remains above 11,864 revision behavior.
For a lack of knowledge on how to mine working with Bazaar, are not
available, this time, the various revisions between one version and
another.
I made a change to code that I would like, in the files
"pen-context.cpp", "pen-context.h", "draw-context.cpp" and "widgets /
pencil-toolbar-cpp" is used function called
"sp_pen_context_set_polyline_mode" that is developed in the
pen-context.cpp file.
This function is used to change the mode (polyline, paraxial ...). I
have seen fit to extend its scope to also define whether we are in
"Spiro" or, in the future, whether we are in "BSpline".
To this I added a boolean property to the object "SPPenContext" called
"spiro" (pc-> spiro) and changed the name of the function in the three
previous files "sp_pen_context_set_polyline_mode" a
"sp_pen_context_set_mode".
On the use of the tool, I had to update the message status bar with the
string "SHIFT for cusp node" and see how they manage the translations.
Usage is simple, clicks create SYMM nodes with "SHIFT" are created but
are mode CUSP.
I ask you to try the code, especially continuing existing lines and / or
closing them.
Greetings.
----------------------------------------------------------------------
Hola.
Acabo de actualizar el branch de SpiroLive siguiendo las indicaciones de
Sorin, con las que estoy de acuerdo. Queda como histórico conteniendo el
anterior comportamiento la revisión 11864 .
Por una falta de conocimientos mios en la manera de trabajar con Bazaar,
no están disponibles, esta vez, las distintas revisiones entre una
versión y la otra.
He realizado un cambio en código que me gustaría comentar, en los
archivos "pen-context.cpp", "pen-context.h", "draw-context.cpp" y
"widgets/pencil-toolbar-cpp" se utiliza una función llamada
"sp_pen_context_set_polyline_mode" que está desarrollada en el archivo
pen-context.cpp.
Esta función sirve para cambiar el modo (polilinea,paraxial...). He
creído conveniente ampliar su alcance para definir también si estamos en
modo "Spiro" o para, en el futuro, saber si estamos en modo "BSpline".
Para ello he añadido una propiedad booleana a el objeto "SPPenContext"
llamada "spiro" (pc->spiro) y he cambiado el nombre de la función en los
tres archivos anteriores de "sp_pen_context_set_polyline_mode" a
"sp_pen_context_set_mode".
En cuanto al uso de la herramienta, me falta actualizar los mensajes de
la barra de estado con el string "SHIFT for cusp node" y ver como se
gestionan las traducciones. El uso es simple, los clics crean nodos
SYMM, con la tecla "SHIFT" se crean pero son de modo CUSP.
Os pido que probéis el código, especialmente continuando líneas
existentes y/o cerrándolas.
Saludos.
10 years, 2 months
Anyone can confirm if this is really a bug ?
by Guiu Rocafort
I'm not really sure about this being really a bug so I'm asking before
creating a bug report.
The bug is checked using Windows 7 64 bits and Inkscape 0.48
The steps for reproducing are:
1. Create empty file.
2. Create a rectangle ( or any other shape )
3. Open Fill and Stroke menu
4. Select Stroke tab.
5. Grab color picker tool.
6. Select any color in the document.
What happens: The fill colour becomes the one picked with the tool.
What I think it should happen: Since the stroke tab is selected, the
stroke colour should become the one selected with the tool and not the
fill colour.
So I am missunderstanding Inkscape or is it a real bug ?
Thanks
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
10 years, 2 months
0.49 release status update
by Josh Andler
Hey All,
It's almost time we move on to Feature Freeze, at this point I'm
saying let's put it out there as November 30th. I had delayed it to
get in a couple new features and the reason I'm not just saying it's
today is to leave it open for John Smith for a shortcut editor akin to
GIMP's (if it can be completed in time).
The current list of bugs milestoned for 0.49 is at 50... and that is
quite high. Can people help reduce this number some? My guess is
things like the tutorial updates for 0.49 are not likely to make it
for example.
https://bugs.launchpad.net/inkscape/+bugs?field.searchtext=&orderby=-impo...
The real issue though is that we currently have 13 blocker bugs, all
but one of which are regressions caused by the new renderer or
rendering cache.
https://bugs.launchpad.net/inkscape/+bugs?field.searchtext=&orderby=-impo...
In addition to these blockers, we still have a security bug that is
blocking 0.48.4 and will also block 0.49.
Please focus efforts on fixing bugs rather than enhancing features at
this point. The two exceptions to this are for the shortcut editor and
the newly committed symbols dialog, polishing things like this is
good.
String Freeze will go into effect on November 30th at this point, but
I HIGHLY recommend translators get started now if they haven't started
already (as was previously recommended).
Unfortunately, it does not look like we're going to be able to get the
release out this year as originally hoped. At the current rate I hope
we can get it out in Q1 of next year.
Sorry for not giving an update sooner. I hope all is well with everyone!
Cheers,
Josh
10 years, 2 months
Cuestion about branches test
by Jabiertxo Arraiza Cenoz
Hello Krzysztof.
Thanks very much. I update the branch and tell in the list the number of
the previous branch whith old staff for posibol regression.
Hi, Jabier.
> On Wed, 2012-11-14 at 13:36 +0100, Jabier Arraiza wrote:
>> Im new to develop whith BZR. I develop a branch, and after i made a
lot
>> of changes on the branch but i want to know what version of code is
>> better.
>> What i do? 2 branches or update original branch whith the new code.
>> The new code is more powerful but im not sure is ok whith the
filosophy
>> of inkscape, because made more changes to the code and change some
>> behviors on usage.
>
> If you want to compare a branch, to let's say trunk you can do that
> using bzr by specifying the branch. So:
>
> $ bzr diff --new lp:inkscape
>
> Would compare to trunk. Usually I find it useful to compare to the
> common ancestor as the diff is a bit cleaner:
>
> $ bzr diff -r ancestor:lp:inkscape
>
> If you'd like to update your branch to include the changes that are on
> trunk currently you can just merge them in. No need to worry about
> rebasing or anything like that, Bazaar handles it for you.
>
> $ bzr merge lp:inkscape
> $ bzr commit -m "Updating to trunk"
>
> It's difficult to know which is "better", but hopefully that helps you
> figuring out the information you need.
This information could be added to our Bazaar tutorial:
http://wiki.inkscape.org/wiki/index.php/Working_with_Bazaar
Regards, Krzysztof
10 years, 2 months
sodipodi:linespacing
by mathog
How does sodipodi:linespacing determine the vertical spacing to the
next line?
From a bit of experimenting it looks like it starts with this:
sodipodi:linespacing="125%"
and then looks at the maximum font size in all of the <tspan>'s
included under the following
<tspan sodipodi:role="line"
and multiplies those together. So if the largest is 16pt, it uses 20pt
for the linespacing.
Is there anything else involved, or is that the entire method?
Also, if this is all inside a <text> with
style="font-size:32.000000pt;font-style:normal;font-variant:normal;font-weight:400;font-stretch:Normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;text-align:start;text-anchor:start;font-family:Arial;"
Changing font-size or line-height makes absolutely no difference in the
display. Is that how it should be?
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
10 years, 2 months
