| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Add a try-catch, so in case setting crop data fails, the size data will
be still set.
|
|
This basically reverts e8f980d10cf95b8bced1ca18a55b2a4784f6dcc9 and
b0e993d42e1df8c68c4c2684ab9dda27a1329594, while keeping callcatcher
happy.
|
|
This reverts commit cf33de27eb5e981d8a1fa76f6a9d72ce7174f10d.
This breaks make bug 20033 detection on Linux. If this can not be reliably
detected on OSX, just disable parallelism for GNU make 3.81 on OSX in general,
but leave the detection intact for Linux.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* SvNumberFormatter::IsNumberFormat() ISO 8601 date input results in
yyyy-mm-dd format if no other date format was set.
* SvNumberFormatter::GetInputLineString() preserves ISO 8601 date format for
editing if such was set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ensure that the printing temp selection document is not destroyed
prematurely by SwXTextView::NotifySelChanged, called via
ViewOptionAdjustStop, by retaining the temp doc object shell not
at the View but in SwRenderData.
Not restoring the view options for selections does not actually work,
because having a selection surprisingly does not imply printing a
temp document: the preview also uses a selection.
(view option regression from cd690d2e72be410058376c416a40ff5d918fb0f7)
|
|
I did not read the code carfully enough when added this line few days ago.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
|
|
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
|
|
|
|
|
|
|
|
|
|
On Android, when an app is installed, arbitrary files bundled in the
app won't be unpacked into actual separate files in the file
system. They will exist only as archive entries in the .apk file
(which is a zip archive).
The SDK tooling puts such files under the /assets folder in the
.apk. The LibreOffice bootstrapping code for Android maps the .apk
file into memory.
osl_openFile() knows about the /assets special case, and uses a
separate abstraction for such memory-mapped files.
Obviously, when producing an .apk, one needs to make sure these
bundled files are not compressed, if one wants to be able to use them
directly from the memory-mapped .apk file. We do that in our test and
sample Android projects.
When mapping such files under /assets , just return a pointer to the
file's location inside the mapped .apk archive.
We can't use the old osl_unmapFile() on such mapped files, as that
would unexpectedly unmap fairly arbitrary pages of the .apk mapping,
wreaking havoc on later use of the same pages.
So, introduce a new osl_unmapMappedFile() function that takes also the
oslFileHandle originally passed to osl_mapFile(). Use this instead in
the few places where the code actually called osl_unmapFile(). Make
sure osl_mapFile() is nonexistent on Android.
|
|
|
|
This reverts commit 070eff8cf1ad7763b8b730336f11032893b77049.
|
|
|
|
|
|
This reverts commit 92f396733ebc518bcb7a9eae2dd3169d333b82b9.
|
|
This reverts commit d00fc0e293852cfc019ffaffa65bee327397677b.
|
|
so that make inside an source ./Env.Host.sh environment
works the same as make outside that env
|
|
|
|
The ones which use a definite 8-bit encoding read/write pascal-style
strings with a 16bit length prefix.
The ones which use a definite 16-bit encoding read/write pascal-style
UTF-16 strings with a 32bit length prefix, i.e. not ByteStrings at all
The "I dunno" ones might be UTF-16 strings or 8-bit strings, depending
on the charset. Rename to ReadUniOrByteString like the other
similar horrors to flag this misery
|
|
Nobody ever used the return values anyway, so for reading just
return the string and for writing the number of bytes written
Doesn't need to be members, make standalone functions
Rename to
read_lenPrefixed_uInt8s_ToO[U]String and
write_lenPrefixed_uInt8s_FromO[U]String, lengthy,
but much less unambiguous, seeing as a lot of users of it don't
seem to be aware that they read/write pascal-style length
prefixed strings, which isn't surprising given the
apparent simplicity of their original name.
added a unit test
|
