Age | Commit message (Collapse) | Author |
|
Change-Id: Ifd51f0c25418085ba8a6e8d331ac5c6d8139d18a
|
|
Yes, a simple test would have answered the question in the comment and
made clear that nanoseconds are not accepted by MSO.
Let's go with normal seconds as MSO does. It seems it also accepts
1/100s but who really needs that for a file timestamp.
Change-Id: Iaec6f9c08dc94d5086b83cb4bf520d0053b71b28
|
|
Change-Id: I6c70c000f60e7e6e43bd068ccb98b693b80746f2
|
|
Change-Id: I78e778408abb72772771daf5776a26f08c313ee2
|
|
Seems poppler changed outputdev virt func signatures with version
12, so with system poppler, we never got any image import functions
called. Added override annotation to prevent this from happening in
the future.
Change-Id: I565de80ce218e831e276d3a1d88ded3baee876e7
|
|
We shouldn't be trying to free the font table buffer when destroying the
blob, so pass NULL for destroy function instead of free(), and also use
HB_MEMORY_MODE_READONLY just to be safe.
Change-Id: I85b5a575249b4efc0f5799db205ee17cbeb66d22
|
|
Change-Id: Id7cb705b2b719cdd3bf16b8aba858c0319686599
|
|
Change-Id: I7a6ee4dce338b7529fa7500bb0c8341a4f2ebc22
|
|
Change-Id: I25794499711845cb8183664d1345e5513587d81c
Reviewed-on: https://gerrit.libreoffice.org/3679
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
|
|
Change-Id: I6ddeff7ae72693fd0951d71bd7b5444938bc7286
|
|
Change-Id: Iaec745dc1c8eb0614cc2fe1d70a94a00d18cc934
|
|
Add "$COMMONPROGRAMFILES\Merge Modules" (on current versions of Windows
that probably is "C:\Program Files (x86)\Common Files\Merge Modules") as
fallback, since for example on Windows Server 2012, the registry entry
has not been created when installing Visual Studio Express
Change-Id: I16f58b8a1d453c8628c6eb66c2cea37ab3da913a
Reviewed-on: https://gerrit.libreoffice.org/3680
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
|
|
Project: dictionaries acf0ae3fdec65df75f4983d2b943582f9ab99fa2
|
|
The things are not even enums, so there's no error checking either.
Change-Id: Ib33cd96b49a840cbe486dbed9a7c370827b54c2d
|
|
And another step closer to opening my test file correctly in Excel.
Change-Id: Ib6aa8ddb2f2792513c7263d86865e08fe5f1483d
|
|
Change-Id: I12ddd18c1b4476d42c097704c2af2d0af4e15a1e
|
|
One step closer to opening my simple test file correctly in Excel.
Change-Id: I1bfa76a46081ba478e44d8d90d8a91790a9a9ff3
|
|
The extra semi-colons were confusing clang. Just remove the macro,
it's not adding any real value.
Change-Id: I7f7c312d2c0167a17e31624e197ae75b77fa0c2f
Reviewed-on: https://gerrit.libreoffice.org/3677
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
|
|
...since 81af84c04fa7ef8c8c12d2a9d3899a9a75cb8260 "gbuild: let JunitTests run
with MSVC."
Change-Id: I4ba97431c3439c0bed74149fe66cbb76db5317ce
|
|
Change-Id: I36c62fc677de70c08d0d59e45debc6a86375d3b7
|
|
...rather than a TypeDescriptionManager service that is no longer available.
Change-Id: I1054ab0a658597a60d11e2f9aa0960df25d14bc4
|
|
Change-Id: I7c750debaeee5d9804be378e0f65bec13ac296eb
|
|
Project: help eddac30b5afa84c2420a553d2e822722dc857228
|
|
Let foo.odb be a database file that has a macro that connects to the
Database on "Open Document" event (and needs to prompt user for
user/password).
There was a race condition between two actions:
1) the asynchronous treatment of "OnFirstControllerConnected" in dbaui::OApplicationController,
which tries to get dbaui::OApplicationController's mutex
2) the StarBasic macro calling dbaui::OApplicationController::connect
which needs to display a dialog (to get username and password),
and thus puts that dialog in the main thread's event queue
and waits for it ... with dbaui::OApplicationController's mutex held
Now, if "1)" is before "2)" in the event queue of the the main thread,
*but* "1)" is executed *after* "2)" has taken the lock, there is a deadlock.
Fix:
1) Make OnFirstControllerConnected synchronous.
Make sure (by taking mutex in dbaui::OApplicationController::attachFrame, its ancestor in the call graph)
that nothing else will happen with the OApplicationController as long as it is not finished.
---> it does not need to take mutex itself anymore
This avoids the "order in the asynchronous events" dependency.
2) Change dbaui::OApplicationController::ensureConnection to do the user prompting
WITHOUT HOLDING the mutex, and use the mutex "only" to protect actually assigning
the connection to m_xDataSourceConnection.
Theoretically, in some race condition, we could connect twice and then discard one connection <shrug>.
ensureConnection will never return the discarded connection, though.
(I think I got that right with respect to http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html)
This keeps it from locking on another condition while holding the mutex.
Change-Id: Iab1bbec5d5df12bb89d027d43e498c78c92ffc32
Reviewed-on: https://gerrit.libreoffice.org/3310
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I2555dc113b2fb4c77bec187b15f0bb545811b07b
|
|
Change-Id: I7a4f782235a23f50bceaef041a92e42e47860a78
|
|
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/3645
Tested-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
|