summaryrefslogtreecommitdiff
path: root/odk/settings
diff options
context:
space:
mode:
authorStephan Bergmann <sbergman@redhat.com>2011-10-21 17:18:13 +0200
committerStephan Bergmann <sbergman@redhat.com>2011-10-24 13:59:58 +0200
commitb786a33cfdca2e8a4114ddef0340e0e0628dd09c (patch)
treea0adbba80933544e1912adeb29a8e79797b7fc1c /odk/settings
parent3535ceeac6f1b4277279082998663feb84d05487 (diff)
Undo basis/brand split: Move SDK and ure-link, remove OOO_BASE_DIR and BaseInstallation.
Diffstat (limited to 'odk/settings')
-rw-r--r--odk/settings/std.mk6
1 files changed, 3 insertions, 3 deletions
diff --git a/odk/settings/std.mk b/odk/settings/std.mk
index 6deb065f9dc1..07266311ca40 100644
--- a/odk/settings/std.mk
+++ b/odk/settings/std.mk
@@ -19,7 +19,7 @@ IDL_DIR=$(PRJ)/idl
BIN_DIR=$(PRJ)/bin
CLASSES_DIR=$(PRJ)/classes
URE_CLASSES_DIR=$(subst \,/,$(OO_SDK_URE_JAVA_DIR))
-OFFICE_CLASSES_DIR=$(subst \,/,$(OFFICE_BASE_PROGRAM_PATH))/classes
+OFFICE_CLASSES_DIR=$(subst \,/,$(OFFICE_PROGRAM_PATH))/classes
COMP_PACKAGE_DIR=$(subst /,$(PS),$(OUT_BIN))
SDKTYPEFLAG=$(OUT_MISC)/oosdk_cpp_types.flag
@@ -27,8 +27,8 @@ SDKTYPEFLAG=$(OUT_MISC)/oosdk_cpp_types.flag
URE_TYPES="$(subst \,/,$(URE_MISC)$(PS)types.rdb)"
URE_SERVICES=$(subst \\,\,$(URE_MISC)$(PS)services.rdb)
-OFFICE_TYPES="$(subst \,/,$(OFFICE_BASE_PROGRAM_PATH)$(PS)offapi.rdb)"
-OFFICE_SERVICES=$(subst \\,\,$(OFFICE_BASE_PROGRAM_PATH)$(PS)services.rdb)
+OFFICE_TYPES="$(subst \,/,$(OFFICE_PROGRAM_PATH)$(PS)offapi.rdb)"
+OFFICE_SERVICES=$(subst \\,\,$(OFFICE_PROGRAM_PATH)$(PS)services.rdb)
OFFICE_TYPE_LIBRARY="$(OFFICE_TYPES)"
generated by cgit (git 2.34.1) at 2024-07-14 13:01:13 +0000
the core specification and in the character names list was differently and more strongly worded, leading to contradictory interpretations. "Given this ambiguity of intent, in 2013 the UTC issued Corrigendum #9, which deleted the phrase 'and that should never be interchanged' from the definition of noncharacters, to make it clear that prohibition from interchange is not part of the formal definition of noncharacters. Corrigendum #9 has been incorporated into the core specification for Unicode 7.0. "Q: Are noncharacters invalid in Unicode strings and UTFs? "A: Absolutely not. Noncharacters do not cause a Unicode string to be ill-formed in any UTF. This can be seen explicitly in the table above, where every noncharacter code point has a well-formed representation in UTF-32, in UTF-16, and in UTF-8. An implementation which converts noncharacter code points between one UTF representation and another must preserve these values correctly. The fact that they are called 'noncharacters' and are not intended for open interchange does not mean that they are somehow illegal or invalid code points which make strings containing them invalid." Change-Id: I4fcc0156e3d2fd305a7c7bb0c7b3dbef846c9e64 Reviewed-on: https://gerrit.libreoffice.org/78598 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-09-04[API CHANGE] rtl_convertTextToUnicode behavior upon erroneous inputStephan Bergmann <http://udk.openoffice.org/cpp/man/spec/textconversion.html> specifies that FLAGS_UNDEFINED_ERROR, FLAGS_MBUNDEFINED_ERROR, and FLAGS_INVALID_ERROR: "Read past the [erroneous] code in the input buffer [...]" But actual behavior of rtl_convertTextToUnicode for the various rtl_TextEncoding values has been inconsistent. Some erroneous input (mostly single-byte UNDEFINED and INVALID ones) has not been consumed at all, some (multi-byte MBUNDEFINED and INVALID) has been consumed partly, and some has been consumed fully as required. However, at least since 8dd4265b9ddbd7786b6237676909eae5b540da0e "CWS-TOOLING: integrate CWS hb18", Custom8BitToUnicode in sw/source/filter/ww8/ww8par.cxx appears to rely on the broken behavior of not consuming erroneous input. (It reads the chunk of valid input with e.g. some RTL_TEXTENCODING_MS_125x that happens to exhibit the broken behavior of not consuming erroneous input, then wants to try to re-read the erroneous input with RTL_TEXTENCODING_MS_1252. For example, opening sw/qa/core/data/ww8/pass/forcepoint50-grfanchor-1.doc triggers that code. For whatever reason, the am_faksas.dot attached to <https://bz.apache.org/ooo/show_bug.cgi?id=9240#c1> "Do not show lithuanian letter 'Š'" appears to not, or at least no longer, trigger that code.) Therefore, it would be useful to have a mode in which rtl_convertTextToUnicode does not consume erroneous input. (And I plan on doing changes in sal/osl/unx/file* that would benefit from that behavior, too.) But changing rtl_convertTextToUnicode to generally not consume erroneous input would not be feasible: If calls do not set RTL_TEXTTOUNICODE_FLAGS_FLUSH, part of an erroneous input can already have been consumed by a previous call, so the current call cannot undo that. But a change that looks like it can work is to change the behavior only if RTL_TEXTTOUNICODE_FLAGS_FLUSH is set. In that case we can at least not consume the part of an erroneous input that has not yet been consumed by a previous call (which would necessarily have been done with RTL_TEXTTOUNICODE_FLAGS_FLUSH unset). The expecation is that code that relies on the don't-consume behavior will do only single calls with RTL_TEXTTOUNICODE_FLAGS_FLUSH set (so reliably not consume the complete erroneous input), while other code (which might do calls in a loop) will not care whether erroneous input has been consumed, anyway. This can be considered a mild form of behavioral API CHANGE (but note that the old implementation didn't exhibit the requested behavior anyway). So all implementations of rtl_convertTextToUnicode for the various rtl_TextEncoding values have been adapted to the new behavior. The only exceptions are ImplDummyToUnicode (sal/textenc/textcvt.cxx), which is a special case anyway used by RTL_TEXTENCODING_DONTKNOW, and two out of three places (marked with a "TODO" each) in ImplUTF7ToUnicode (sal/textenc/tcvtutf7.cxx), where it is hard to retrofit the expected behaivor, and RTL_TEXTENCODING_UTF7 is probably not relevant for the use cases relying on the don't-consume--behavior, anyway. Whether a similar change should be done for rtl_convertUnicodeToText can be examined later. Change-Id: I1ac2c4cfd99e2a0eca219f9a3855ef110b254855 Reviewed-on: https://gerrit.libreoffice.org/78584 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-09-03Fix handling of invalid bytes >= 0x80 in ImplUTF7ToUnicodeStephan Bergmann Change-Id: I08838f9ae34a31712d7269ddaaee3fe59ece2178 Reviewed-on: https://gerrit.libreoffice.org/78562 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2018-11-17Adapt to C++2a char_tStephan Bergmann u8 literals incompatibly change their type (as implemented by recent Clang trunk) Change-Id: Ia4f7b91f5d86656a056303d2754981ab2093a739 Reviewed-on: https://gerrit.libreoffice.org/63494 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2018-06-29Improved loplugin:redundantcast (const-qualified typedefs): salStephan Bergmann Change-Id: I64b6ffd3e43f14c5884bf6cf1c12ff3b147db6bd Reviewed-on: https://gerrit.libreoffice.org/56699 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2018-01-12More loplugin:cstylecast: salStephan Bergmann auto-rewrite with <https://gerrit.libreoffice.org/#/c/47798/> "Enable loplugin:cstylecast for some more cases" plus solenv/clang-format/reformat-formatted-files Change-Id: I7d89b011464ba5d2dd12e04d5fc9f65cb4daebde 2017-10-23loplugin:includeform: salStephan Bergmann Change-Id: I539ca8b9dee5edc5fc2282a2b9b0ffd78bad8b11 2017-09-24Map Windows code page 42 to RTL_TEXTENCODING_SYMBOLStephan Bergmann <https://msdn.microsoft.com/en-us/library/windows/desktop/ dd374130(v=vs.85).aspx> "WideCharToMultiByte function" suggests that there now is CP_SYMBOL, "Windows 2000: Symbol code page (42)." And a little test program on Windows indicates that our RTL_TEXTENCODING_SYMBOL is working the same way as CP_SYMBOL, where MultiByteToWideChar maps 00..1F to U+0000..1F and 20..FF to U+F020..F0FF. At least CppunitTest_writerfilter_rtftok, when testing writerfilter/qa/cppunittests/rtftok/data/pass/EDB-18940-1.rtf, goes into case RTF_FCHARSET in RTFDocumentImpl::dispatchValue (writerfilter/source/rtftok/rtfdispatchvalue.cxx) with nParam matching aRTFEncodings[2] (i.e., a mapping from charset 2 to codepage 42, see writerfilter/source/rtftok/rtfcharsets.cxx), then passes 42 into rtl_getTextEncodingFromWindowsCodePage and obtains an unhelpful RTL_TEXTENCODING_DONTKNOW. testFdo72031 (sw/qa/extras/rtfexport/rtfexport2.cxx, CppunitTest_sw_rtfexport2) needed to be adapted, as the circled plus from the Symbol font is now internally represented as U+F0C5, not (somewhat bogusly) as U+00C5 (aka LATIN CAPTIAL LETTER A WITH RING ABOVE). But, when displayed with the Symobl font, the glyph that is actually shown remains the circled plus. Turns out changing rtl_getTextEncodingFromWindowsCodePage would start to make CppunitTest_sw_rtfimport fail: Sep 20 15:49:24 <sberg> vmiklos, with <https://gerrit.libreoffice.org/#/c/42477/>, testN823675 (sw/qa/extras/rtfimport/rtfimport.cxx) fails, the aFont.Name is not "Symbol"; sw/qa/extras/rtfimport/data/n823675.rtf contains a \fonttbl that specifies \f3 to have \fcharset2 (i.e., symbol font) and fontname "Symbol". However, RTFDocumentImpl::checkUnicode (writerfilter/source/rtftok/rtfdocumentimpl.cxx) converts m_aHexBuffer (containing "Symbol;") with nCurrentEncoding apparently being the encoding specified by \fcharset2 (i.e., now RTL_TEXTENCODING_SYMBOL instead of old RTL_TEXTENCODING_DONTKNOW), so the resulting OUString is garbage (instead of the byte-for-byte conversion to Unicode "Symbol;" that RTL_TEXTENCODING_DONTKNOW would do there); do you know whether such \fonttbl fontnames should actually be interpreted in the given \fcharset? Sep 20 15:49:24 <IZBot> gerrit: »Map Windows code page 42 to RTL_TEXTENCODING_SYMBOL« by Stephan Bergmann for master [NEW] Sep 20 15:51:15 <vmiklos> sberg: let me check if the spec covers that Sep 20 15:54:29 <mst_> sberg: i think the name is typically encoded in the font's encoding but probably they have to make a (likely undocumented) exception for symbol encoding Sep 20 15:57:46 <vmiklos> sberg: the spec only says that \fcharset is about the encoding of the content using that font, i don't see it described what would be the encoding of the font name itself Sep 20 15:58:51 <vmiklos> sberg: i'm not sure about if that encoding should or should not affect the encoding of the font name in general, but indeed at least for 2 (symbol encoding) you're right, Word doesn't encoding the font name with that encoding, either. Sep 20 15:59:30 <sberg> vmiklos, mst_, at the top of page 14 of Word2007RTFSpec9.docx I see "Note that runs of text marked with a particular font index (see \fN in the Font Table section) use the codepage for that font as given by \cpgN or implied by \fcharsetN, unless they use Unicode RTF described in the following section." Would that match what mst_ says? Sep 20 15:59:33 <vmiklos> so if it helps you case to handle at as e.g. ascii, just for that encoding, i think there would be no problem with that. Sep 20 16:00:07 <vmiklos> sberg: that still talks about the content using the font, not the strings (font names) in the font table itself, i think. Sep 20 16:01:17 <sberg> vmiklos, what's the control word to select such a font, also \fN? I don't see any such in n823675.rtf Sep 20 16:02:16 <mikekaganski> loircbot: e.g. \af3 Sep 20 16:02:31 <mikekaganski> sberg: ^ Sep 20 16:02:47 <mst_> 04d5a280beeeb6e056df68395dc9c3b3a674361b Sep 20 16:02:50 <IZBot> core - related: fdo#77979: writerfilter RTF import: read encoded font name - http://cgit.freedesktop.org/libreoffice/core/commit/?id=04d5a280beeeb6e056df68395dc9c3b3a674361b Sep 20 16:02:52 <mst_> sberg: ^ Sep 20 16:04:05 <sberg> mst_, thanks; so there's likely an (implicit?) exception for \fcharset2, as you say Sep 20 16:04:33 <mst_> that's most plausible, our own font code is full of exceptions for "symbol fonts" too Sep 20 16:05:19 <sberg> mikekaganski, ENOCONTEXT Sep 20 16:05:36 <mikekaganski> sberg: [17:01:16] sberg: vmiklos, what's the control word to select such a font, also \fN? I don't see any such in n823675.rtf Sep 20 16:06:32 <sberg> mikekaganski, so you say selection is done with \af3 instead of \f3? Sep 20 16:06:40 <mikekaganski> sberg: yes, in that case Sep 20 16:07:34 <mst_> i think there are several different keywords that apply fonts, but can't remember the whole list Sep 20 16:08:10 <mst_> \fN shoudl be one of them though Sep 20 16:22:18 <sberg> vmiklos, so who generated that sw/qa/extras/rtfimport/data/n823675.rtf, was it manually created and lacks a \cpgN before "Symbol"? Sep 20 16:29:17 <sberg> vmiklos, (after further reading of the RTF spec): disregard the "and lacks a \cpgN before 'Symbol'" part of my above question Sep 20 16:30:27 <mst_> sberg: i suggest not reading too much about encoding in RTF, it gets pretty lovecraftian pretty fast... Sep 20 16:32:58 <vmiklos> sberg: given how short that bugdoc is, i'm pretty sure i cut it down manually to something readable from a multi-MB real bugdoc Sep 20 16:33:07 <sberg> mst_, do you have a recommendation how I could get that "don't use symbol font encoding to read a symbol font's name" into writerfilter/source/rtftok/rtfdocumentimpl.cxx? RTFDocumentImpl::checkUnicode lacks the context to tell whether it is using m_aStates.top().nCurrentEncoding to convert a fontname, and the caller of checkUnicode (at the end of RTFDocumentImpl::resolveChars in this case) appears to lack the context, too Sep 20 16:33:12 <mst_> various Old Ones from The Time Before Unicode and their Backward Compatibility Tentacles etc. Sep 20 16:34:59 <sberg> vmiklos, anyway, that "so there's likely an (implicit?) exception for \fcharset2" hypothesis sounds sane, so we should probably implement it (if only you or mst_ can give me a good hint how...) Sep 20 16:35:13 <vmiklos> sberg: looking for a code pointer Sep 20 16:36:05 <mst_> sberg: m_aStates.top().eDestination == Destination::FONTENTRY should be the relevant check? Sep 20 16:36:17 <vmiklos> sberg: RTFDocumentImpl::text() is where the text is taken, Destination::FONTENTRY is the state on the parser stack which is a font entry in the font table. so to detect "your case" during decoding a byte array into a string, m_aStates.top().eDestination == Destination::FONTENTRY is what you want Sep 20 16:36:35 <vmiklos> ah good, two independent matching hints are promising ;) Sep 20 16:37:35 <sberg> mst_, vmiklos, ah; but what also looks dodgy is that checkUnicode operates there on "Symbol;" including the closing ";" of the full <fontinfo>, not just the <fontname> part of the <fontinfo> Sep 20 16:39:24 <vmiklos> sberg: i think we already assume that the only "token" in the font entry destination that is not bound to a control world (\foo) is the font name Sep 20 16:40:52 <vmiklos> sberg: writerfilter/source/rtftok/rtfdocumentimpl.cxx:1237 is where we simply strip away the trailing semicolon, there is no further separation between the font name and other character content inside the destination (apart from the control words and their arguments) Sep 20 16:42:18 <sberg> vmiklos, OK, thanks; I'll just pretend I haven't seen those dodgy details :) ...so I'm switching to (somewhat arbitrarily) RTL_TEXTENCODING_MS_1252 there now Change-Id: Iebd1bcecb7fa71c489798154d3356062b052775e Reviewed-on: https://gerrit.libreoffice.org/42477 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Stephan Bergmann <sbergman@redhat.com> 2017-09-13Make reading UTF-8 strictStephan Bergmann Consider non-shortest forms, surrogates, and representations of values larger than 0x10FFFF (which can even cover five or six bytes, for historical reasons) as "invalid" (they used to be considered as "undefined" instead). This is in response to fc670f637d4271246691904fd649358ce2e7be59 "svtools: HTML import: don't put lone surrogates in OUString" (which can now be reverted again in a follow-up commit). My fear would have been that some places in the code rely on the original, relaxed handling, but at least 'make check' still succeeded for me. Change-Id: I017e6c04ed3c577c3694b417167f853987a1d1ce 2017-07-17RTL_UNICODETOTEXT_INFO_{DEST|SCR}BUFFERTOSMALL should use TOO, not TOChris Sherlock I have kept the old mispelled constant for backwards compatibility Change-Id: I128a2eec76d00cc5ef058cd6a0c35a7474d2411e Reviewed-on: https://gerrit.libreoffice.org/39995 Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com> Tested-by: Chris Sherlock <chris.sherlock79@gmail.com> 2017-06-14use more SAL_N_ELEMENTS part 2Noel Grandin Change-Id: If00e371c3cd3ae616309a172c875faed016e391b Reviewed-on: https://gerrit.libreoffice.org/38773 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> 2017-04-28loplugin:salunicodeliteral: salStephan Bergmann Change-Id: I1b7c3f8de5b09c96e27aa9124096b00638afb3f3 2016-07-13sal: fix remaining loplugin:cppunitassertequals warningsMiklos Vajna Change-Id: I9f9b647ed73e06a5e926eff8f95dda92fec134c0 Reviewed-on: https://gerrit.libreoffice.org/27177 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> 2015-11-10loplugin:nullptr (automatic rewrite)Stephan Bergmann Change-Id: I1bc6c87fcd6e5e96362623be94c59be216a3b2b8 2015-07-09Do not call SAL_N_ELEMENTS on empty arrayStephan Bergmann Change-Id: I8b73c61a9662079927344029eb9872c6a19aad76 2015-01-07loplugin:cstylecast: salStephan Bergmann Change-Id: I0ad9681a8b31d78cefce5b66040415154a1c7a99 2014-12-19No need for RTL_USING in addition to LIBO_INTERNAL_ONLYStephan Bergmann Change-Id: Iaa65658aed6bb4abb20a4d95dc9c6caf7c1c764b 2014-11-17sal: clean up public headers with include-what-you-useMichael Stahl Sadly cannot forward declare "struct {...} TimeValue;". rtl/(u)?string.hxx still include sal/log.hxx but removing osl/diagnose.h was painful enough for now... Change-Id: Id41e17f3870c4f24c53ce7b11f2c40a3d14d1f05 2014-07-01New loplugin:stringconcatStephan Bergmann Change-Id: Id7c517fb37bc28797c45fc0dde83e866f2aa4aac 2014-04-24More hacking on --with-localesTor Lillqvist Propagate the restriction of locales into <config_locales.h>. Note that in the normal case, with no locale restrictions, all the WITH_LOCALE_xx macros are zero anyway, but WITH_LOCALE_ALL is one. Restrict which character encodings are handled in sal/textencsal/textenc/tables.cxx based on the WITH_LOCALE_ macros. (Don't simply always do it for iOS.) Massage the affected unit tests to not crash when only partial character encoding information is present. Change-Id: Ie2c882c262ebd0d2b37dde66b8fe3c3e2570da14 2014-04-24Get rid of the "failure #23" style messages in CppunitTest_sal_rtl_textencTor Lillqvist While at it, print the character values in assertion messages in hex, not decimal. Change-Id: I61a5efca0a800ea295afc81e2b2f234844428b1c 2014-04-24Add missing right paren in assertion log messagesTor Lillqvist Change-Id: Ia6f3f0f74b6de127d8989935e10c15a6cf52e5d7 2014-04-23Make assertion failures in CppunitTest_sal_rtl_textenc more informativeTor Lillqvist I have plans to change the sal textenc stuff to use ICU so better assertion messages is essential. Change-Id: I764a317435b6bd7c88d6e42fcfbefb1ec9c308fd 2014-04-03Kill superfluous vertical whitespaceTor Lillqvist Change-Id: I8c37b9ec45836f9c0e2dc0cf232f96f23c7c36d3 2014-03-01Remove visual noise from salAlexander Wilms Change-Id: Idf07c7d31c0a523f929aded9ff3183a3f01b16b9 Reviewed-on: https://gerrit.libreoffice.org/8297 Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com> 2013-02-22silence warning.Michael Meeks Change-Id: Ibf82038c15c9ecf6de502bae1dd21e2393cafe09 2012-11-27implement a new iscii (devangari) <-> unicode converterCaolán McNamara this time with support for the multi-byte encodings possible in ISCII Change-Id: I1dc09e8836676ab614b531e8dc10f91a90b7c4fd 2012-11-26get textencoding tests working againCaolán McNamara Change-Id: Ia3e0b7be14800e1d50c3e785153b45d2b4a7dd6d 2012-11-21re-base on ALv2 code. Includes:Michael Meeks Patch contributed by Herbert Duerr: #i118662# remove berkeleyDB from module xmlhelp (author=orwitt) http://svn.apache.org/viewvc?view=revision&revision=1213188 #i119141# remove ISCII converter for now http://svn.apache.org/viewvc?view=revision&revision=1306246 make exceptions for cppunittester verbose http://svn.apache.org/viewvc?view=revision&revision=1174831 Patches contributed by Pedro Giffuni: Avoid some uses of non portable #!/bin/bash in shell scripts. http://svn.apache.org/viewvc?view=revision&revision=1235297 Patch contributed by Oliver-Rainer Wittmann 88652: applied patch, remove unicows deps http://svn.apache.org/viewvc?view=revision&revision=1177585 drop OS/2 code, remove in-line assembler ARM atomics, and obsolete armarch header. 2011-11-27remove include of pch header from salNorbert Thiebaud