Age | Commit message (Collapse) | Author |
|
Change-Id: Ib935ebd1609d4584d464e42fa418c2e91202e59b
|
|
Change-Id: Ib0329b9cdc4290ce98c4182e8466c1b44b408341
|
|
Change-Id: I415769aeda335d65a4a5dc03be56e26a860046e3
Reviewed-on: https://gerrit.libreoffice.org/2067
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
|
|
This should make it handle paths with spaces properly.
Change-Id: Ic4e36449435e1bab2441ea011ccea018f14b98cf
|
|
Change-Id: I6daea312198fae3a9717bd8d4fea6371aa4cd275
Reviewed-on: https://gerrit.libreoffice.org/1962
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
|
|
Change-Id: I4f37cb4bcde935bfbf6d412f4c81ef0451245f00
|
|
Change-Id: I2e28b9f9d52bcb01b04f98d39d12b6d8a627bec5
Reviewed-on: https://gerrit.libreoffice.org/2043
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
... throws IndexOutOfBoundsException, since it's not supposed to happen.
Change-Id: I876e6cede88f86d12543d3ce65e1b0a0ca5389a7
|
|
Change-Id: Id989bcf78fc10eb29e9afd89c71e2deb2b98b4d3
|
|
Change-Id: Ia7d0de2c3017f450b9ace31753a351601ca6f1f0
|
|
Change-Id: I0a44bab196ae239d3bdea75fd2b657bdfa4ecf31
Reviewed-on: https://gerrit.libreoffice.org/2011
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: Idf7cb08121cae2c183ed5bc012d848b31429ff49
|
|
Change-Id: Id7c9ff4c7d7da830f9fdfb5046b627b5235c19be
Reviewed-on: https://gerrit.libreoffice.org/1951
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I0669a75fcb91a2b713212983d6e04a5e17e297c4
|
|
replaced Len() with isEmpty() where appropriate
Change-Id: I5a5847d6055f376fd5f86079aa1736541d790fff
Reviewed-on: https://gerrit.libreoffice.org/1892
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
|
|
Change-Id: I4b7fa3fd01717105af194a04b73d90e0d602028a
|
|
Change-Id: I40a52bdca7884b092aa395d0afd0ffa5364f4ebc
|
|
For non-homogeneous (the default) button boxes we want in general to give all
buttons the same width as the max button width.
But if we detect that certain buttons are > 1.5 the average button width, then
leave those outliers at their natural size and set the rest of the buttons to
the max width of the remainder.
Change-Id: Ice514e741e3a7725d69e150e5752158a1c267141
|
|
Otherwise e.g. informing about new fonts when loading a document
with embedded fonts doesn't work. I'm not quite sure why this
should be limited to only printers or pdf, so this may be temporary
until a problem shows up. There'a also a warning about refcount
in ImplFontCache::Invalidate(), which seems to be bogus, because
invalidating caches shouldn't have effect on anything except for speed,
but with the way font handling in vcl is designed I wouldn't be
surprised if ImplFontCache wasn't actually a cache.
http://lists.freedesktop.org/archives/libreoffice/2012-September/038163.html
Change-Id: Ib68c0c10a0f5340a532c5c59396ef2cfbc588b5f
|
|
Change-Id: If3607886050c4e2e649e5678cc39f290b122f537
|
|
Change-Id: I44686ea724873181018bf00253a08afa58c9a10b
|
|
Change-Id: I8fd733fe6535cc4f9f299f53adc1821ce344a85c
|
|
...see the comment at the start of InitSalMain in
95548c7b5ad2b388f077bf9bf2031ac5f6121d0e "Implemented InitSalMain() and
DeInitSalMain() functions" for why this was relevant back in 2001.
Change-Id: I2b2e5f261065d3b801ef20cca592009fa6b3f558
|
|
Change-Id: I1d97ba1cc643fb1c940b94e84e348812efae115b
|
|
Change-Id: I65e68de95ff30b74fe7052dc4a7429d49536b564
|
|
Change-Id: I1e5777e5dcc04d0aa53d1ac4b9091f310ae59035
|
|
These bad calls to putenv suddenly caused the buildIdFile string (macro-expanded
from bootstraprc's UserInstallation) in cleanExtensionCache
(desktop/source/app/app.cxx) to contain nonsense at least in a local
libreoffice-4-0-0 of mine, as getenv("UserInstallation") started to return some
non-null pointer pointing to garbage.
Change-Id: Ib93fd4e1caef016bd0e00bf09800b9532824ac4b
|
|
It no longer gets stuck in a loop so easily.
The key thing I realized was that there is a fundamental difference to
how the ATSUI and CoreText APIs handle text buffers and the start
offsets into them:
ATSUCreateTextLayoutWithTextPtr() takes a pointer to the whole buffer,
plus start offset and length. These are stored as part of the layout
object. Other ATSUI calls that use the layout object interpret index
parameters as relative to the buffer start, not relative to the start
offset of the layout object.
CTTypesetterCreateWithAttributedString() on the other hand takes an
attributed string that has been created from a CFString that already
is based on a potential substring of a buffer. I.e. the CTTypesetter
has no knowledge of the original buffer. All index parameters are
relative to that substring of the buffer, as are return values.
Change-Id: I7026f323d90a72e1ae1784a69f521e347baffaea
|
|
The CoreTextLayout class is clearly based on the ATSLayout class, so
in order to make it easier to compare code of the two, rename fields
back as they are in the latter. Also add the corresponding comments
where applicable.
Once the CoreText code fully works and has superseded the ATSUI code,
sure, we can change field naming convention if we want.
Change-Id: I0d47ad0206fa895339506471bb638bd04f426490
|
|
To make it easier to compare to what goes on in the corresponding
CoreText layout code.
Change-Id: I18478cb7e28827a512b50573c8f7ac84b1cf1ece
|
|
Change-Id: Ib51e7c95a807c988da87068d8d2e49773a41282e
|
|
Change-Id: I7217ab7500de5d8220b85e56aceb6e843bd0769f
|
|
Change-Id: I54d8923ad315e8041fd3904da3a29f1a7a8c8b16
|
|
Change-Id: I7eccac4fa8890c2873c6bbd7f8f5bf5b0dd006d2
|
|
- do not use gb_UnpackedTarball_copy_header_files for boost
- adapt the optimization in concat-deps.c for new path
- use boost_headers in all LinkTargets that require it
- add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus
Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
|
|
auto-adding mnemonics to the first character of OK/Cancel translations suggests
short-cuts under various CJK/Indic languages which can't be achieved with a
single keystroke combination
Some platforms want mnemonic-ed OK/Cancel, some don't. So lets have two
translations, one for each situation, rather than trying to automunge.
Change-Id: I23e21e79b27ead86f535309ca0efc2adea86ae24
|
|
Two Gradient instances equal if all of their members equal, not any.
Change-Id: I313c1b145005f295f47b27e7af7ec96d5ee6168f
|
|
Change-Id: I169d9e95a2ac1f22bc94e46781bfcee07b133ad4
|
|
removed temporarily added OUString(...GetSavedValue()...) constructs again
Change-Id: I11477654d217a5ae127c1ef1b19cbff56ed052a6
|
|
Change-Id: I13db34f37caeb44ab622b94d2e23ac1727182c8b
|
|
Change-Id: I64e43e472215df35872e447e381047e64002184b
|
|
...in X11SalGraphics::GetGlyphBoundRect
In MultiSalLayout::GetBoundRect we loop through each fallback font and union
each level's GetBoundRect to get the result, which seems reasonable, except
that for each level that means a call to SalLayout::GetBoundRect which calls
X11SalGraphics::GetGlyphBoundRect.
Those sublevel SalLayouts don't know that they are sublevels so they never set
the level bits on their glyphs. Which results in
X11SalGraphics::GetGlyphBoundRect always searching for that glyph in the level
0 font, so there's a mismatch between the font the SalLayout's are created to
use and the font that gets used.
Now, SalLayout::GetBoundRect is a fairly simple thing, it just calls
GetNextGlyphs 1 by 1 and X11SalGraphics::GetGlyphBoundRect on the result of
that. So I *think* that if we remove the specialized
MultiSalLayout::GetBoundRect in favour of the default implementation, then
because MultiSalLayout::GetNextGlyphs is specialized to do-the-right-thing and
set up the glyph ids correctly, then we bubble the ids down
to X11SalGraphics::GetGlyphBoundRect correctly to get it to
use the right font and we get the correct bounding size.
defb4d60a2d22fd36a0ff3f077faa6a0932b45a4
defb4d60a2d22fd36a0ff3f077faa6a0932b45a4
Change-Id: Idefb4d60a2d22fd36a0ff3f077faa6a0932b45a4
|
|
Change-Id: I624f35026b8ee847d70d429c61cd93d6a603d8b0
|
|
Lots of code relies on the fact that the two bitmaps inside a
BitmapEx actually have the same size. Enforce that convention during
import.
Change-Id: I436ccc33b06c627cd6347747d22c24bfaf7ca932
|
|
Change-Id: Ifea57dec77c5b23771684a1e46267f8431478075
Reviewed-on: https://gerrit.libreoffice.org/1806
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: Ib6d94e6e695d4c675c05954fbf28af61bbaa05fe
|
|
Change-Id: I185cedfaff30063fe0d0deb64eecff8796ac1ff9
Reviewed-on: https://gerrit.libreoffice.org/1813
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
Tested-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: I0e9460adeebb2e2a46ca3cd0e683cd4f0026916b
Reviewed-on: https://gerrit.libreoffice.org/1775
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>
|
|
Change-Id: Ie5df8819c59135625f504f7d5b6736ddab7aab53
Reviewed-on: https://gerrit.libreoffice.org/1774
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Tested-by: Petr Mladek <pmladek@suse.cz>
|