Monday, September 30, 2013

GSoC 2013 - Character border

Character border (fdo#35155)

In this summer I participated in Google Summer of Code and implemented border on the character level. So in the next 4.2 version of LibreOffice users will be able to set border around a run of characters.

Two example of character border. Above there is a drop cap letter with double border and blue background. Under there are two words with a blue border around it plus a box-shadow on the top-right side of the border.

The character border can be specified as a direct formatting via Format -> Character -> Borders tab and it also can be the part of a character style (e.g. Format -> Styles and Formatting -> Character Style). One special case of the latter is drop caps character style.

Drop Caps

While I was working with character border and I was testing whether it works in all cases I realized that Drop Caps has some bugs which keep me from adding my new feature. So I have to solve them before I able to keep on my original project:

1. User defined background was shifted upward
Two parts of the picture shows the background painting before the bug fix and after that. Before the default gray background was hanging out from behind the user defined yellow background. The after part shows that after fixing the bug only the user defined yellow background is painted.
Since border is drawn at the edges of the background, it was also drawn at the wrong place.

2. Changing line height
A drop caps with the deafult gray background and a red arrow showing that the first line of the paragraph next to the drop cap has bigger height as it is expected.
Height of the first line was changing unexpectedly when the drop cap letter's original height was bigger than the height of the following characters. Original means the height which it would have if it wasn't a drop cap. By now this original height is ignored during height calculation of the first line.
Since border rendering increase this height with the border width, line height also increased with this width.

3. ODF import loses drop caps character style (fdo#43807)
It also loses the border including by this character style.

Border merge

The implementation of character attributes and the specification of ODF file format make it necessary to add automatic border merge functionality. Border merge means that if two text ranges have equal border (same line, padding and shadow) they will be rendered inside the same border.

Above there is a text with two bordered text range with one Q letter between them. After this Q letter is removed the two border text range are merged and so are rendered within the same border.

Border merge also means background merge, since this is a general concept to draw border at the edges of the background.
When there are letters with different sizes and they have background then this background's height will depend from the height of the text. So letters with different size will have different hight background. But if this letters are merged to one border group then they will have a coherent background.

File formats

List of file formats to which/from which Writer exports/imports character border:

Monday, June 17, 2013

LIMIT improvements in LibreOffice 4.1

Some new things get into this version of LO.

1. The primary improvement is adding a combobox to the design view and so not needed to use SQL view to limit the number of resulting rows. This new edit is get place on the query design toolbar and in the Query Properties dialog (Edit -> Query Properties).

Place of the new toolbar item is on the rightmost side of the query toolbar.
New toolbar item to limit a query result
in query design view.

Query properties dialog has the same box as the query design toolbar. These two box are in sync.
New dialog to add query properties like limit and distinct values.

2. LO uses HSQLDB (version 1.8.0) as an embedded\default database so this is an commonly used driver for Base. However it has a bug which lead to an exception when user intend to run a query like "SELECT * FROM table LIMIT n". The problem is HSQLDB's parser does not handle "LIMIT" as an keyword and so in this case "LIMIT" parsed as a table alias and the following number as an unexpected token. Inside LO this bug is fixed by now.

An error box saying the number after the LIMIT is unexpected.
In older versions, HSQLDB throws an exception when
use LIMIT directly after from clause.

The rows are listed with expected number.
LO 4.1 doesn't throw the HSQLDB's exception and return
with the expected result.

Of course it also means LIMIT keyword can't use as a table alias anymore in LO as it was used before. These usage is stand only when use "Run SQL command directly" option. (LO has an own parser which notice that LIMIT is a keyword and so can't be a table alias, but with this option this syntax check can be avoided)

Limit used as an table alias in SQL statement and Base return with all elements of the table without problem.
Before, user was able to use LIMIT as a table alias.

An error box is opened which say that LIMIT is unexpected token.
LO 4.1 throws an exception, when use LIMIT as a name
(get from fixed HSQLDB)

3. This is my favorite. In SQL mode, in the SQL edit the LIMIT keyword was highlighted wrong as a single name (green colour) and not as a keyword (blue colour). The origin of this problem may be the same as in case of HSQLDB's bug. The LIMIT keyword got into the code later as other keywords and it was missed to add all of places where a keyword has to appear.

In the SQL edit the LIMIT word has green color.
Before, the LIMIT keyword was highlighted
with green color like a simple name.

In the SQL edit the LIMIT word has blue color just as the oder keywords like SELECT, FROM and so on.
In LO 4.1, the LIMIT keyword has the same highlighting as
other keywords (blue character color).

Thanks for Foundation for funding this work!