Change-Id: I55447aba5abcc8205543c7ca64763b5c99854837

See the comment in climaker_app.cxx main about room for improvement.

Change-Id: I11cc2f62c9d42269d5c96253198ee4e730496e75

Change-Id: I2ff65979a9da7da12ad6ac97dc090898913a2e8c

Change-Id: I181c87f8406f095bd4dc499b47d91081f58aaf59

Project: help  7584ed08efd8e9cea733a782544a1e1eeb48433f

Build tools do not link against merged libraries but individual small
ones we need for this (gb_BUILD_HELPER_LIBS).

Change-Id: Ia765e11a93ed05d126334a3e146fb88e368954ac

Change-Id: I801f4af269efcea91bc3bafbfc9e0b9033488f2d
Reviewed-on: https://gerrit.libreoffice.org/3645Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: If6caa7abed25ce95f1c62f9673619426eb49b5a8

Change-Id: I47f1a72fac3e6678b5dfe880f2f189ffc436333b

IMHO there is no reason why they should be 0444. I have found no
explanation for it, either in the commit that introduced the bundled
dictionaries or in the related bug.

Change-Id: Ia42218a0d579ced5f17248a092eab2c61cb9005f

Change-Id: I3edbae98c9bb51899e5592fae1cfe9f3632ad535

It turned out that ApplyDXArray() is need to apply advance width
adjustments after justification, so we can't just bypass it.

So I just copied GenericSalLayout::ApplyDXArray() and stripped it of
ICUism so it does not break with HarfBuzz, but I had to make
m_GlyphItems non-private, so I'm not sure this is the right approach.

Change-Id: I66d647c3590fdf912c39d0cf23ac72bcc7ca72c9

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>