The 3rd parameter to hb_buffer_add_utf() should be the length of the
whole text not the current run, so that HarfBuzz can take the context
into account when shaping.

Change-Id: I9e4e928d40078c3e3667cfdb6d8f24bf6e58263d

No more second guessing if text width, we know that information already,
so pass it around instead of trying to re-create it.

Change-Id: I19faacbc309d38753c3c9f7214dfa0bf59cc66b5

Not that I'm a fan of Hungarian notation, but for the sake of
consistency. Fix some placement of opening braces along the way.

Change-Id: Id6ea758fd438a4040e7451430a0f3a166efdec43

Change-Id: I78efebb576dffa8d39e98283feb9aab2186b5a39

GenericSalLayout::GetTextWidth() uses GlyphItem's mnNewWidth when
calculating text width, and though this seems logical (it is after all
the actual with the glyph is contributing to the all over advance
width), it results in shorter width calculation whenever glyph width
adjustment is involved, no idea why!

The #ifdef is there so that the ICU code path is not changed in anyway,
but all of this should be merged into GenericSalLayout when ICU is
gone.

Change-Id: I7cbde1675b78e87c142513eb52a13ee5fdc60617

Use local variables instead of altering the returned glyph positions
array, looks more cleaner this way.

Change-Id: Ibbcced57777010bd045668a99d7beb0618abe226

X and Y offsets should only affect the position of the current glyph,
not any subsequent ones.

Change-Id: I9dd1576cbdbb36b70f1898dc52702c02c4e851af

It turns out it is GenericSalLayout::ApplyDXArray() that is messing with
glyph advance widths trying to recalculate them. It is very old code (it
has been there since ICU were introduced back in 2002), but whatever
issue it is fixing, HarfBuzz does not need it.

Change-Id: I5c896d3f318e2f17d135f9eea599b917e04ed592

Change-Id: I7943c7e388b1cb73311d666ff600a31ac70c2838

Change-Id: I459f847a67282bd1e3dc914e25a39815a6e177a0

Change-Id: Id6c566ada50bd4d6f4043bbff25114e7872b7cc8

Project: help  0021ca3f232ca48538685fc75e70616d5e12c407

Change-Id: Ie8c3d30cb28afb97d4ded4ac67241ed18ab9e50c
Reviewed-on: https://gerrit.libreoffice.org/3651Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: Ia36b42be8f5caa93937e870467c95f47439d9c9e

Project: help  53c7b09224a3206cc72f65a4001b32e912ca5a45

Change-Id: I79c5b123abf671d51deadd56644271124420ce64

when you change the text direction it should update the numerical type but it dosen't.
this patch will get you out of edit mode before changing text direction and after finish the change it will get you in again

Change-Id: I5598fd9dab823c738a812537743695ec88690a24
Reviewed-on: https://gerrit.libreoffice.org/3629Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: I25140e854458186c7f66aba1baeabd5fadb3e162
Reviewed-on: https://gerrit.libreoffice.org/3655Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Change-Id: I1961da149ed350131e19233bd5694ae8b6fe65ba

Change-Id: Ie08a7312df0d42efc3697089cf766ceeefd623b0

Change-Id: I04d9988ab2035ec2d68fac19f506a6b461e4d257

...which lead to std::unoexpected from sw/PythonTest_sw_python.

Change-Id: I94bdbbe131a7c65c363f7aa66e8d8df7bd531449

...whereby some branding could be orverridden with information from a program/edition/
directory.

Change-Id: I7f9324678b09bc8069775dfcbda97be8e0618a91

New keywords can now simply be added to a static array rather than
adding a new "else if" blocks for each keyword.

Change-Id: Ib581b3e834a57e0dfa9d139bcb4ae7a0a52a5472

The ctor later will turn that reference to a pointer anyway, but the old
code made it easy to pass a String, get it implicitly converted to
OUString, and then we took the address of the temporary OUString, later
resulting in accessing already freed memory. Instead, take an OUString
pointer, and then the compiler will warn about a String* -> OUString*
conversion. Adapt one remaining caller accordingly.

Change-Id: I4084dea1d245f0c8919d6afe47c5f391729f6eaf

Change-Id: If629068fee488abbad9704b8300e59ea4c5c8605

Change-Id: I0b479500938e185fb6d163837b29e6e36e823260
Reviewed-on: https://gerrit.libreoffice.org/3641Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

IMO Calling this method again is not required. The If Blocks returns
false when User Clicks "Cancel" Button in "Format Cell" Widget,
IMO on Cancel Their is no need to Update the table. And on Ok
SetAttrToSelectedCells method is called which inturn calls
UpdateTableShape() method.

Change-Id: I2bb0bb616cc978717a1494e01f257631aadd613c
Reviewed-on: https://gerrit.libreoffice.org/3391Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

Iterate over all selected cells, set appropriate alignment based on
current writing direction and alignment of the cell.

Don’t change alignment when cell is center aligned or justified.
and if alignment is right or left, change it respective to writing direction.

Change-Id: Ie98a46af97236ab4303d030f11bd167939dde32b
Reviewed-on: https://gerrit.libreoffice.org/3549Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>

By removing the last two libs: nullcanvas and directx5canvas.

directx5canvas seems to be dead and nullcanvas don't have entries in scp2.

Change-Id: Ib8fc1da123f8374fb83192f14db730638213f564
Reviewed-on: https://gerrit.libreoffice.org/3626Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Cleanup of source code:
- translated German to English
- removed useless comment decorations
- removed commented out code
- some reformatting of code

Change-Id: I71d5fdab8226d61bda9ac906bb82176dc11cafd2
Reviewed-on: https://gerrit.libreoffice.org/3643Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

My simple test file is finally valid but is still now shown in Excel.
There must be another bug in our exporter.

Change-Id: Ib55e5b32edc3a556e9081b3008df539275dc289b

c:characters does not have an attribute val. The value has to be written
out as normal string.

Change-Id: Icd2c4034918bd223d0c8082a7d137e1ce79a9cfe

this fixes one validation error with documents containing charts

Change-Id: I879963484b1cc00322e8c79bf77dfbbf91869587

This does not work yet as we have several validation errors in our
exported OOXML chart doc. I have to clean them up before the documents
are accepted by Excel.

Change-Id: I0bba64a9c6cab489199c8e6f04158fea7b953d0a

Change-Id: I74a4dfcebd61ca1b6befa9f49214e4155ce0bd34

Change-Id: I70be33bc4843a19a24ce2fcb0cda094684557c04

Change-Id: I969217263fdda3e61b38dc16f0a9251b745de885
Reviewed-on: https://gerrit.libreoffice.org/3652Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Change-Id: I0727b800c715962a88e256b30046c9e13d6bd2a9
Reviewed-on: https://gerrit.libreoffice.org/3650Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>

Change-Id: I5f2cdcd8a17ca250413bda066acaeab24118f9d6