- Inkscape Devel - Inkscape Mailman

Translations and r11895 bug in flow text
by Jelle 28 Nov '12

28 Nov '12

Hi Guys, Just to report that r11895 has a rather ugly bug in the flow text. After creating an initial text, I wasn't able to edit it anymore. Unfortunately launchpad is in the 3 second zone of timeouts for me in Chongqing, China and I've never been able to use it, otherwise I'd add the bug list there. Please bear with my good intention. And David, If you've ever imported a PDF file with lots of text in layouts, you may have noticed that every single character gets a position. Now that's fine until you try to change the text in any way as the text string will change, but not the positions string. In other words, you end up with garbage. The workaround for that is to use the split text extension. Which cleans up all the manual kernings nicely. Maybe that can lead you to solve your problem as well, as it seems related. Cheers Jelle > Message: 8 > Date: Mon, 26 Nov 2012 13:08:16 -0800 > From: mathog <mathog@...1176...> > Subject: Re: [Inkscape-devel] tspan Text Starts > To: <inkscape-devel(a)lists.sourceforge.net> > Message-ID: <a3d4787463b3de4b4f2a326b82cdf6ab@...2855...> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 23-Nov-2012 19:48, Martin Owens wrote: >> 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? > > Hmm. Well, this may not be what you are after, but... > > I have been working on code to reassemble formatted, editable text from > component pieces. The idea is that something like > this in Inkscape: > > (E:bold)(=mc:no special formatting)(2:superscript) > > when present in an EMF or PS file, for instance, is represented by 3 > separately formatted text strings: > {E,=mc,2} > > These are currently read back into Inkscape as just those pieces. It > looks exactly like the original, but the pieces > are not assembled, so the whole is not editable. My code tries to > reassemble the pieces from its position, font information, etc. and > makes <test><tspan> records to match. This work is not done but the > current version does pretty well at figuring out where paragraphs start > and end, figures out the justifications and so forth, and generating > editable Inkscape SVG. It works with rotated text, but at present > cannot figure out when the first sentence of a paragraph belongs with > the remainder if the first is indented by starting it an offset (as > opposed to by using leading spaces.) > > For your purposes, would it be sufficient if after reassembly the > formatting information was discarded and just the logical > information retained? That would give you sentences and paragraphs > (super and subscripts would be problematical.) > > Regards, > > David Mathog > mathog@...1176... > Manager, Sequence Analysis Facility, Biology Division, Caltech

3 2

May I have a wiki login to fix the documentation about the windows command line
by Justin Dearing 28 Nov '12

28 Nov '12

Hello, This page does not mention inkscape.com versus inkscape.exe. I wasted many hours yesterday, eventually discovered this: http://kaioa.com/node/63 and this morning after discovering this http://stackoverflow.com/a/8030880/95195I realized my problem is I was executing inkscape.exe and not inkscape from the command prompt. I'd like to clarify the issue so others do not go down the same path. Justin

3 2

Obscure kerning issue
by mathog 27 Nov '12

27 Nov '12

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

1 1

tspan Text Starts
by Martin Owens 27 Nov '12

27 Nov '12

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

2 5

Updated code in SpiroLIve
by Jabiertxo Arraiza Cenoz 27 Nov '12

27 Nov '12

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.

1 0

Tiling tool
by Tom Lechner 26 Nov '12

26 Nov '12

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

3 3

Sorin based SpiroLive behabiours
by Jabiertxo Arraiza Cenoz 26 Nov '12

26 Nov '12

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.

1 0

Anyone can confirm if this is really a bug ?
by Guiu Rocafort 21 Nov '12

21 Nov '12

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

5 9

0.49 release status update
by Josh Andler 20 Nov '12

20 Nov '12

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=-import… 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=-import… 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

3 3

PDF X-3
by john Culleton 20 Nov '12

20 Nov '12

An Inkscape file can be saved as PDF 3 or PDF 4. What are the prospects for PDF X-3 being added to the list? -- John Culleton Wexford Press Free list of books for self-publishers: http://wexfordpress.net/shortlist.html PDF e-book: "Create Book Covers with Scribus" available at http://www.booklocker.com/books/4055.html

2 1