Simple String Handling
by Martin Owens
Hi devs,
I've tried out the following patch:
http://paste.ubuntu.com/6809633/
And it's not working. The path which used to work well, it now being
overwritten with garbage data before the file can be opened. As if the
reference has been freed.
I'm sure it's something simple to do with those consts or gchar types.
Any ideas?
Example output:
** (inkscape:4946): WARNING **: Can't open file: /home/doctormo/D\x89
\x99 (doesn't exist)
** (inkscape:4946): WARNING **: Can't get document for referenced URI:
inner.svg#bar
Martin,
9 years
Removal of popt
by Krzysztof Kosiński
Hello
The bug which is keeping us with popt has been recently fixed.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
This means we can remove several kb of code and remove one of our
dependencies by changing command line parsing from popt to GOption.
Since the bug was Windows-specific, we can do this once the next
stable version of glib is released.
Regards, Krzysztof
9 years
Re: [Inkscape-devel] Why is the position of this line of code so touchy?
by Krzysztof Kosiński
2014/1/24 mathog <mathog@...1176...>:
>> This line is completely equivalent to replacing it with a call to
>> cairo_save and adding a call to cairo_restore at the very end of the
>> containing scope.
>>
>> You cannot move this line into a different function, because then the
>> destructor (and hence cairo_restore) gets called when decorateItem()
>> returns.
>
> Except my code ONLY works if it is moved into another function! That's what
> is driving me nuts. I will have to trace this code thoroughly, as there
> must be a dangling transformation or an extra cairo_restore or cairo_save
> somewhere.
Please post a more complete listing of the good and the malfunctioning
version of your code. I'm sure we'll find the problem then. The "call,
line1, line2" etc. descriptions in your initial e-mail are a little
insufficient to figure out what is going on.
> I guess. I am not a fan of implicit side effects unless there is absolutely
> no way around it. Here
>
> dc.save()
> blah
> dc.restore()
>
> would have worked, and it would have been immediately apparent to a
> maintenance programmer what was going on. Or is the ::Save stuff in there
> to clean up in case there is an exception and the code jumps to a handler,
> without ever returning from these functions?
You can add an early return and forget about adding the cleanup code,
there can be an exception, or you can simply forget about adding he
restore(). The ::Save object ensures proper cleanup in all of those
possibilities.
Regards, Krzysztof
9 years
C++ explanation please
by mathog
Sometimes it is hard to shake off decades of C programming, so please
bear with.
In src/display/drawing-context.h near the top one finds:
class DrawingContext
: boost::noncopyable
{
public:
class Save {
public:
Save();
Save(DrawingContext &ct);
~Save();
void save(DrawingContext &ct);
private:
DrawingContext *_ct;
};
and in drawing-context.cpp those methods all use ct and _ct for the
variable names.
Which is all fine and would be no issue at all, except that below the
lines just cited in drawing-context.h every place one finds a reference
to ct or _ct it is a cairo_t or a cairo_t*, not a DrawingContext.
Can somebody please explain why it is considered helpful in C++ to use
"ct" to mean two different things like this in the one header file?
The disadvantage of doing it the way it is now is that when somebody
like me encounters _ct elsewhere in src/display, and looks for it like
this:
grep '[\* ]_ct[; {]' src/display/*.h
it finds two definitions:
DrawingContext *_ct;
and
cairo_t *_ct;
with the end result that one must read the file to figure out what is
actually going on.
Had the first set used "DC"/"_DC", for instance, there would have been
no confusion, and the second step would have been eliminated.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years
Fwd: Re: C++ explanation please
by mathog
On 22-Jan-2014 13:39, Johan Engelen wrote:
> You have to trace the scope hierarchy
> manually (e.g. function body -> class declaration -> base class
> declaration(s))
This is probably a rant...
Never mind tracing the variables, tracing execution to see which parts
are actually used can be tedious too. I spent too much of the last day
doing just that.
Experimental text decoration display is currently in trunk, along with a
patch (in Launchpad) that modifies the Text and Font dialog to allow
crude editing of those properties. Now one might think that since Cairo
is used for the display, and Cairo is used to render to PDF (and
others), that implementing a type of draw for display would
automatically show up in render. Nope, none of the text decorations
render to a file. As far as I can tell the display and render functions
are both intertwined, and separate.
This is what happens when Inkscape saves to a PDF (just the highlights,
obviously a lot of other stuff goes on too). Starting at (A)
src/extension/internal/cairo_render_pdf_out.cpp
(A) pdf_render_to_document_file()
(C) (->B)
(H) (->I)
(T) DONE!
src/sp_item.cpp
(B) invoke_show
(->D)
(G) (return ->H)
src/libnrtype/Layout-TNG-Output.cpp
(D) Layout::show
(->E)
(F) (return ->G)
(L) showGlyphs
(->M)
(P) (return ->Q)
src/display/drawing_text.cpp
(E) addcomponent
(add a glyph to a list, copy some parts of style into _nrstyle)
(return ->F)
(Z) _renderItem (draws glyphs for cairo for DISPLAY of text)
src/extension/internal/cairo_renderer.cpp
(I) renderItem
(->J)
(S) (return ->T)
(J) sp_item_invoke_rendering
(->K)
(R) (return ->S)
(K) sp_text_render
(->M)
(Q) (return ->R)
src/extension/internal/cairo_render_context.cpp
(M) renderGlyphText
(->N)
(O) (return ->P)
(N) showGlyphs
(draws glyphs for cairo for RENDER of text)
(->O)
When text is displayed (on the drawing surface) it also follows a call
to addcomponent (E) and (if there are changes(?)) Layout::Show (D), but
goes through _renderItem (Z) in src/display/drawing_text.cpp, which is
never called in the trace above. Text display doesn't touch the rest of
the trace shown above. In _renderItem it deals with an object
DrawingContext, whereas in the trace above it carries around an object
CairoRenderContext. In terms of activity both of these objects are just
wrappers around Cairo - but exceedingly different wrappers. _renderItem
is fairly similar to renderGlyphText (M) [but ironically, not to
renderItem(I)], so renderGlyphText (M) is one logical place to patch in
text decorations for render. However, when I implemented
text_decoration display, which is called from _renderItem (Z) the code
naturally used DrawingContext and _nrstyle (E), and neither of those is
available in renderGlyphText (M), which greatly complicates implementing
text decoration for render.
Maybe text draw and text render were designed to be this different, but
it feels an awful lot like an instance of divergent evolution.
Regards,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years
Href sub-document model (Martin Owens)
by Jelle Mulder
Hi Martin,
Let me start with telling that I'm thrilled that you're doing work on
external <use> links and have some working code. I hope it will find its
way into the 0.91 version as it will make my life so much easier.
However, while you're at it.
Three questions arise.
- Can this mechanism be used to add external CSS as well? I know Bruno
Wick is working on that as well, but it seems you're on a roll here and
would be the missing link (pun intended).
- Would it be possible to create a save option where such external files
are concatenated into one big whopper of a file? Or even better, send it
all to a single root file of users choice (oh joy!)? With some nice check
marks to add or not CSS, external <USE> objects, etc? It would solve a
problem for all those browsers that do not support external linking or
have bugs*.
*(like webkit that supported external links till Chrome version 19 and
then Blink had this nice regression that yet has to get solved. Opera
works fine till version 12.5 and then they went Blink, Firefox can only
handle links one directory level deep these days, sigh. I foresee a
brighter future though)
- And the very whopper question that probably stretches your patience..
How about kicking all <use> objects to external files and style info to
external CSS? <script> to external files? Again with switches for each
type of export. I gather this to be a whole other ball game and probably
not ready for 0.91, but what power would that give to Inkscape as
authoring tool for web projects!
Ehm,.. sorry if this abuses the dev list as it sounds very much like
something I should throw at the bugtracker wish list, but 95% of my
request get timed out due to latency I experience in Chongqing, China, so
I never manage to send something there. On the other hand, I think it is
on topic.
Jubilant cheers,
Jelle Mulder
> Message: 1
> Date: Tue, 21 Jan 2014 11:09:58 -0500
> From: Martin Owens <doctormo@...400...>
> Subject: [Inkscape-devel] Href sub-document model
> To: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net>
> Message-ID: <1390320598.10117.59.camel@...2056...>
> Content-Type: text/plain; charset="UTF-8"
>
> Hey developers,
>
> This is the model I'm going to implement for documents to reference
> other documents:
>
> SPDocument {
> GSList *child_documents;
> SPDocument *parent_document;
>
> // Parent of parents until parent == NULL;
> SPDocument *getRootDocument();
> }
>
> Then in uri-reference, check paths of existing child_documents, load the
> referenced document and add to child_documents. Set parent_document.
>
> That should keep things consistant.
>
> The idea here is that we'll use this to track documents referenced in
> <use tags> as well as <image tags> and attributes like 'marker-*:
> url(...);' but not for non-vector graphics used in the image tag.
>
> Thoughts? Advice?
>
> Best Regards, Martin Owens
9 years
What is the intended purpose of this line of code?
by mathog
Hi all,
While trying to find a place to patch in text-decoration writes so that
they show up in cairo based file types (PDF and the like), I noticed
that simple multicharacter tspans were being broken into single glyph
writes by this line in TNG-Output.cpp:
&& (font_matrix * glyph_matrix.inverse()).isIdentity()
because the test is always false. Here is the link to it in context
(barring edits to that file in a revision after I send this)
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/l...
If that one line is commented out it lets something like
<tspan>123456</tspan> pass through to renderGlyphtext() in one big
chunk, but other than that, it doesn't seem to make any difference.
Can somebody tell me why that test is there? It seems to be doing the
wrong thing in all the test cases I have run through it, unnecessarily
breaking up the writes, but that doesn't mean that it does not resolve a
problem that arises in some case I have not yet considered.
Thanks,
David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech
9 years
Compile Inkscape - Problem Link DLL and .lib file
by naim
Hi
I got a DLL and its .lib file that expose some functions. I need to use
those functions to customize Inkscape.
My question is, how do I configure build.xml so that compiler will link the
.lib file?
Thanks,
Naim
9 years
