The SDK tooling that constructs .apk packages doesn't put empty
directories in them. Which makes sense I guess. "Hidden" files (like
.gitignore) are also skipped. So a directory like
sc/qa/unit/qpro/indeterminate does not show up at all.
So, we must pretend that any opendir() of a directory under /assets
succeeds. If the .apk doesn't contain any files in such a directory,
treat it as existing but empty. We can't know if the corresponding
directory from which /assets was constructed actually does exist but
is empty or if it doesn't exist.
Like any of our executables using <sal/main.h>, it doesn't even build
for iOS anyway using the current <sal/main.h> anyway, as there is no
main() ;) Executables for iOS (i.e. unit testers, and some eventual
end.userish apps) will be handled "semi-manually" in some yet to be
worked out fashion.
Makes no sense for Android either, but I'm lazy.
Previously all frames were opaque by default, which is the Writer but
not the docx/rtf default. Change the default, while keeping the
possibility to set an opaque color background for the frame.
If we have a duplicate font entry the duplicate is dropped, but
if the first font was invalid, e.g. .pfb without .afm this results
in dropping *both* fonts, the valid and invalid one
708def7d94 made that code conditional on !$do_link
so that it worked right for the case where making dev-install calls ooinstall
-l. However, that code now starts to fail also in the --disable-linkoo case
(where building dev-install calls ooinstall w/o -l). I have no idea whether
that code serves any real purpose in any actual use case, so remove it
completely for now.
When two (or more) text frames was imported without a non-frame
paragraph in between, the first frame was anchored to the second one,
instead of a non-frame paragraph.
The fix is modelled after what the old RTF import already did in
SwRTFParser::Continue() in swparrtf.cxx:493 and
SwRTFParser::SetFlysInDoc() in rtffly.cxx:481.
Otherwise the package creating code (part of the SDK) won't include
them and/or the package installation code (on the OS itself) won't
unpack them. (They just silently skip the file.)
Would it perhaps have been better to always link with gb_STDLIBS
without having to mention it in each Library_*.mk and Executable_*.mk?
And then for those few exceptions come up with some "No STDLIBS,
thanks" thing?
