Caolan McNamara

For debugging mail problem, e.g. when debugging some emailmerge stuff in LibreOffice recently, fakemail was really really handy when you have a bug which requires generating a couple of hundred emails in quick succession to trigger.

Released libexttextcat 3.2.0 (Extended Text Categorization used to guess the language that input text is written in). It can be found in this download dir. No code changes from 3.1.1, but adds a large collection of extra language signatures to nearly add the same language support to libexttextcat as LibreOffice supports, modulo languages that LibreOffice supports which don’t have a convenient UDHR translation to use as a basis to generate a language fingerprint.

As Lior Kaplan demonstrated at LibreOffice 2011 Paris, our format character preview really sucks for CTL and CJK users. If no CTL/CJK text is selected then no CTL sample text is shown, and the CJK sample text is from the fontname itself. Many font names are just Latin text, so give no indication what they look like in the actual script/language that is being written in.

e.g. Old dialog for CTL, will only preview some Western text if no text is selected, no attempt to show any sample CTL text, or even the CTL fontname. For CJK it will additional show the fontname of the CJK font in the preview, which isn’t helpful if the CJK fontname contains no CJK glyphs.

Simply adding the CTL fontname wouldn’t help much, seeing as the fontname is David CLM. So, currently reusing the preview text used in the font-dropdown first stab at “doing the right thing” gives me…

Code for all this is mostly in svtools/source/misc/sampletext.cxx where there is now some hugely over-engineered set of heuristics to guess the best script a font is tuned for and various functions to generate suitable text when all we have is the font, versus the font+language vs just the language and if we want a short identifier to classify what script a font might be good to render vs a longer sequence of sample text for a font preview.

Probably best to drop rendering the fontname in the Western case for the text preview and use some sample text there too, at least for the mixed Western+CTL+CJK case as its confusing to have a font name rendered and some sample text in another font.

—

After initial posting, there was some comments about the hideous rendering of the Hebrew text, which appears to be an artefact or using David CLM. Here’s what it looks like with David, i.e. its the rendering using that font that misplaces the Nikud, not me. Whether this is an interesting bug in our renderer, or maybe glyph fallback, or the font itself it probably worth of investigation.

Looking through my fonts that are clearly tuned for a single specific script, there remain two scripts that niggle me as I don’t have suitable sample text for them. i.e. PhagsPa and Tai Le. I’m looking for a short snippet of sample text in those scripts which is suitable to stick into the font drop down preview. Ideally something fairly equivalent to “Alphabet”, “Script”, “PhagsPa/Tai Le” or “Tibetan/Tai Lü”.

LibreOffice inherited a text language guesser, based on textcat from wise-guys.nl and extended by Jocelyn Merand to basically handle UTF-8 text. This is the thing that makes the suggestions as to what language your text might really be in when you right click on some misspelled text and chose set language.

We’ve now spun this off as a standalone libexttextcat and fixed up some conversion problems from the original selection of 8bit encodings and generated new language fingerprints in other cases, which should give better results for various languages, and allow us to enable checking for some languages which was disabled until now.

The current list of languages it attempts to detect can be seen here

Here’s a plausible process to add your favourite language to it, given git clone git://anongit.freedesktop.org/libreoffice/libexttextcat and bootstrapping from the insanely-translated UDHR using Abkhaz as an example.


cd libexttextcat/langclass/ShortTexts/
wget http://unicode.org/udhr/d/udhr_abk.txt
#skip english header, name result using BCP-47
tail -n+7 udhr_abk.txt > ab.txt
cd ../LM
../../src/createfp < ../ShortTexts/ab.txt > ab.lm
echo ab.lm ab--utf8 >> ../fpdb.conf


Then update the check target in src/Makefile.am to confirm the detection of ShortTexts/ab.txt as ab works using make check

I’ll remove the necessity of a configuration file in a later version, and convert the result to a BCP-47 tag. For the moment it remains a drop in replacement for the original solution which necessitates retaining the slightly odd language tag syntax.

Maybe there’s something to the cult-of-git after all . vcl/unx/source/fontmanager/fontcache.cxx had some code which painstakingly constructed a string, only to do nothing with it. Clearly at some time in the past it was used, so when did its use go away. This is a file which has been moved around over the years from place to place, hmm, potentially tricky to scratch the itch of knowing when it happened ?, not at all…

git log --follow --oneline -S'suspiciously missing variable' /path/to/file.cxx

and 2 seconds later I have a list of 5 commits, there it is at the top of the list. Back in 2005, a rework of the font cache where the stat on a file was optimized out, while the constructed path to the file remained. No undetected nightmare merge bug then, just a missed micro optimization opportunity.

So, as of today all LibreOffice (3.5 onwards) text rendering under X goes through cairo. This was already the case in practice for horizontal text for quite a while, the additional change is that its true for vertical text as well now.

before

after

Yes, I know it’s still rather sub-optimal. The current implementation is basically intended to be bug-for-bug compatible for now, though I couldn’t resist improving the positioning of 0x30FC.

Test-case at http://cgit.freedesktop.org/libreoffice/core/tree/qadevOOo/testdocs/vertical-testcase.odt

I wonder if anyone has any sgv documents left around, not svg, but sgv, the StarDraw 2.0 format. Looking for .sgv documents that contain text, and ideally text outside of the ASCII range. A few umlaut’s would probably suffice.

The return of callcatcher derived lists of unused code list in LibreOffice. I tweaked callcatcher to understand the additional gcc command line options used by the new gbuild module so it can be dropped in as a gcc replacement in that environment.

There’s now a findunusedcode target in the top level Makefile and a cached list of easy to remove methods in the tree as unusedcode.easy. These are non-virtual C++ methods which are not called directly, nor have their address taken by any code in a stock debug level Linux build.

What distinguishes unusedcode.easy from not-easy is simply that the easy list is restricted to C++ name-mangled class-level symbols and so omits any non-mangled C-style symbols which might be dlsymed from some not easy to find entry point.

At a count of 5176 easy unused methods there’s enough there to be getting on with for the moment, and can revisit the C-style symbols with a whitelist of known dlsym names on completion of those.

For regression testing LibreOffice filters I’ve now arranged things so that each import filter’s cppunit test comprises of three data dirs, a pass dir, a fail dir and an indeterminate dir. Files in pass must parse without error, those in fail are expected to fail, but fail gracefully by returning an error or throwing an exception, i.e. a crash is a fail on a “fail” test, while “can’t parse” is the expected pass state.

The pass/fail dirs are typically pre-filled in the tree with a small sample of tricky documents which get tested at every build time to ensure they remain working.

indeterminate dirs on the other hand are expected to be empty in the tree, and the cppunit tests don’t care if their contents can be parsed or not, only that they don’t crash. This is really convenient for searching for crashes in a large document collection (horde), given that its an order of magnitude faster than using the full application to load and layout the results.

So I/we can just take a large document horde of e.g. docs and throw them in sw/qa/core/data/ww8/indeterminate and run make -sr in sw and sit back and wait to see if anything in there is a crasher at the parser level. For extra goodness export VALGRIND=memcheck to run the whole lot under valgrind.

FWIW, today anyway

1. All 3721 attachments of (alleged) mime-type application/msword in openoffice.org’s bugzilla pass without crash when placed into ww8/indeterminate. To be re-run under valgrind later
2. And all (ok, only 128) attachments of (alleged) mime-type application/msword in freedesktop.org’s bugzilla pass under VALGRIND=memcheck when placed into indeterminate.

I’ve got doc, rtf, qpro, wmf, emf, hwp, lwp and sxw organized and pre-seeded with a sample handful files so far. Plenty more filters than that of course, but .doc is my current focus as the richest vein of available had-bugs-reported documents.

I’ve been somewhat remiss, our new baby Naoise being held by his big sister.

So, what’s wrong with this picture…

void AnimationNode::acquire( ) throw ()
{
OWeakObject::acquire();
}
...
void AnimationNode::release( ) throw ()
{
OWeakObject::acquire();
}

Don’t need to know anything about the code in question to have grave doubts about a “release” method that has the same body as its “acquire” method .

This big old leak in presentation animation nodes is fixed now

So Sébastien (Le Ray) strikes again. I like autocorrect, I know a lot hate it, but I generally like it, but it drives me insane when it does the wrong thing, e.g. you type http:// at the start of a sentence, and it autocorrects to Http://. So now it simply doesn’t autocorrect protocols when you type that :. http://, ftp://, etc. now stays as http://, ftp://

So, one of those little annoying things. Headings sorted awkwardly.

and now after Sébastien Le Ray’s mods:

ta-da.

The current font drop down had a few small annoyances in it, it previews the font by rendering the font’s name in that font itself, but assumes that the same point size in any given font will have the same baseline and height as the default UI font, which leads to misplaced entries and cut-off text, e.g.

The other gripe is the positioning of the extra preview text used if the font is a symbol font or cannot render its own name, e.g.
the positioning of the symbols of OpenSymbol,

So, now (checked into 3.4) the preview is more carefully vertically centred and scaled to fit if necessary. e.g.

Additionally the extra preview text is right aligned (also checked in for 3.4). For extra cunning (to be checked in today) when the font is tuned for rendering a specific script e.g. Arabic or Telugu, then some sample glyphs from that script are shown as extra preview text, seeing as its not massively useful to get an Latin script preview of the fontname which the massive likelihood is that its not really intended for use for that script, effectively guaranteed in the case that it doesn’t even have sufficient glyphs in it to render its own name. In most cases the string for each script is hopefully that scripts major language’s translation/equivalent to “Alphabet” or some such.

And under windows a sample preview a sample pair of Windows simplified and traditional Chinese fonts

I’ve now received my 20th near identical spam mail about “I recently bought a Samsung Wave S8500 with Samsung Bada OS when will your software be available for it”. I beginning to feel a deep dislike of the device and its OS. A word to the wise, If this is a guerilla marketing attempt, then it’s going badly wrong.

Taking Alan Ning STL performance comparison of VC9, VC10 and STLPort I converted it over for Linux (available here) and compared the built in STL of gcc 4.5.1 on x86_64 versus STLPort 4.5 both at -O2. Tests and test-descriptions below are lifted directly from Alan. Times are actually in milliseconds, not seconds, but I didn’t bother regenerating the graph legends.

Lower bars are better, hardware is an i7 with 6 gigs memory.

The test for vector involves three operations – insertion, iterator traversal, and copy.

Native STL consistently faster.

Native STL consistently faster.

The test for string involves three operations – string copy, substring search, and concatenation.

Native STL apparently worse with strings with approx more than 3200 characters.

Native STL typically slower.

The test for map involves insertion, search, and deletion.

Native STL typically worse with maps over 200 elements.

Native STL typically faster.

The test for Deque comes with a twist. The deque is implemented is as a priority queue through make_heap(), push_heap() and pop_heap(). Random items are inserted and removed from the queue upon each iteration.

Native STL faster.

Native STL faster.

In general the gcc STL looks comparatively good with the exception of large maps.

Cedrics’s LibreOffice first-week codeswarm video is just so cool

I rather dislike “the community” as a term, it’s too easy to mentally substitute it as other people or useful idiots.

Threads, window managers and complex text layout.