Estimated read time: 1 minutes
I got a report about two problems which got fixed in master now.
The first error is triggered, if you have special (in RTF terms, so for
example { or }) characters in style names. The result was not so
friendly when you opened such a document:
After applying the first fix, the document was imported but the original Тест text was replaced by something non-unicode:
The second fix addresses this, and now the result is the expected one:
Estimated read time: 1 minutes
There was a thread about this topic already, but just refusing to commit new files without documentation sounded too aggressive. So the current code just prints a warning.
It was also requested to show some good/bad examples. Lubos volunteered to add detailed instructions in the wiki, so I’m just describing in short what did I test so far.
A good example:
/// Handles export of foos using RTF markup class RtfFoo { };
A bad example:
class RtfBarBuggy { };
Example output when a warning is emitted:
~/git/libreoffice/master/sw$ git commit -a -m foo
sw/source/filter/ww8/bar.hxx:30: warning: Compound RtfBarBuggy is not documented.
[master 1b11571] foo
3 files changed, 68 insertions(+), 0 deletions(-)
create mode 100644 sw/source/filter/ww8/bar.hxx
create mode 100644 sw/source/filter/ww8/foo.hxxEstimated read time: 1 minutes
I’ve got a report which turned out to be two separate issues. One is a regression from Go-OO 3.2.x, this post is about this part. The other part is about the improvement of both the import/export RTF filter, the bug has some detail on that part as well.
So the problem was that wrapped images (when the image is a frame and not a character) had some extremely small height. I did not notice this bug in LO as an LO-specific extension hides that value, but in Word you can see it:
The fix is to use the height of the containing frame instead of the height of the picture itself, then it’ll look fine:
Estimated read time: 1 minutes
About four days ago it has been asked on #libreoffice if it’s possible
to bind functions to F13..F16 in Calc. The short answer is no, but it
turned out it’s pretty trivial to allow that (and of course not only in
Calc).
Cedric’s great post is helpful here to find the relevant code. It also truned out that VCL already supports those keys, so only the user interface has to be improvied to export that feature.
The patch is here.
Estimated read time: 1 minutes
Background: OSL_TRACE() is an internal LibreOffice macro that is like
printf(), but it’s only enabled in debug mode. Without it, you would
add a debug printf during development:
printf("debug, foo\n");
then you would comment it out when the code started working,:
//printf("debug, foo\n");then remove the comment when it breaks again, etc.
In the past, if you built a LibreOffice module, then you executed:
buildinside a module, and in case you wanted debug symbols and such messages you built using:
build debug=twhich increased the debug level to 2 (from 0), where 1 is required for debug symbols, 2 for debug messages. (See the OOo wiki page.)
The recent update, why I’m writing this post: Now this has been
changed,
and debug=t gives you debug symbols only, but no extra debug output.
While this is
great
in most cases, sometimes you still want the old behaviour to get the
debug messages. In that case the solution (as pointed out in the mailing
list post) is to use:
build debug=t dbglevel=2(Hopefully this post will be handy for who missed that post, like I did the first time.)
Estimated read time: 1 minutes
Estimated read time: 1 minutes
So I have been invited to this year's openSUSE conference in Nurnberg to give a short presentation about my GSoC work (the RTF export rewrite in LibreOffice).
As I expected, the really interesting part was to meet people I never had the ability to meet in person previously - and of course to learn other new stuff. :)
So some of the items I really liked:
To sum up: thank you for the invitation, I enjoyed it! :)