[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 Marcus changed: What|Removed |Added Status|VERIFIED|CLOSED -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 Andrey Repin changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #54 from Andrey Repin --- It seems fixed on my end. At least, I'm unable to reproduce the original issue using AOO4115m2(Build:9813) - Rev. 5f13fa0070 from 2023-11-20 17:44. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 Matthias Seidel changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #53 from Matthias Seidel --- Setting this as FIXED now... Please test with AOO 4.1.15-RC2: https://dist.apache.org/repos/dist/dev/openoffice/4.1.15-RC2/binaries/ -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 Matthias Seidel changed: What|Removed |Added Target Milestone|--- |4.1.15 --- Comment #52 from Matthias Seidel --- Cherry-picked for AOO42X with: https://github.com/apache/openoffice/commit/2a19c4c2b3b9385d8893e4a44875be5775525cd0 Cherry-picked for AOO41X with: https://github.com/apache/openoffice/commit/5f13fa00702a0abe48858d443bc306f5c5ba26d8 -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 Matthias Seidel changed: What|Removed |Added CC||msei...@apache.org --- Comment #51 from Matthias Seidel --- Committed to trunk with: https://github.com/apache/openoffice/commit/f0439fff86115a6959e104fea345d175528afdf0 -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 --- Comment #50 from Czesław Wolański --- Hi Arrigo, Just tested on Windows (7 & 11) with - ru (full) - en-US (full) + ru (langpack). It works i.e. no problem with "Save As...". -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 --- Comment #49 from Arrigo Marchiori --- Here is an English US build: http://home.apache.org/~ardovm/openoffice/bug126680/Apache_OpenOffice_4.1.14_Win_x86_install_en-US.exe It _should_ also work if you install this and then a langpack from 4.1.14. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 --- Comment #48 from Arrigo Marchiori --- A Russian build for Windows of version 4.1.14-RC1 that includes the patch is available here: http://home.apache.org/~ardovm/openoffice/bug126680/Apache_OpenOffice_4.1.14_Win_x86_install_ru.exe Feel free to contact me if you would like to test builds for other languages. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 --- Comment #47 from Arrigo Marchiori --- Pull request: https://github.com/apache/openoffice/pull/171 -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 Peter changed: What|Removed |Added CC||pe...@apache.org --- Comment #46 from Peter --- > This does not seem right IMHO. Removing that part allows each > TransliterationWrapper > instance to have its own Transliteration_caseignore instance. I agree. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 --- Comment #45 from Arrigo Marchiori --- At a second thought, forcing all transliterations to follow the same rules may not be the correct way to follow. This bug shows that different parts of the code require different transliteration rules. This can be confirmed by searching the code for instantiations of the TransliterationWrapper class: main/basic/source/runtime/methods.cxx main/sc/source/core/data/global.cxx (2 occurrences) main/sc/source/ui/docshell/impex.cxx main/svl/inc/svl/ondemand.hxx (2 occurrences) main/sw/source/core/bastyp/init.cxx main/vcl/source/app/i18nhelp.cxx Plus all the occurrences of OnDemandTransliterationWrapper::get(). It may make sense to have several Transliteration_caseignore instances, instead of a "singleton". The Transliteration_caseignore class itself does not seem to have been designed to be a singleton, IMHO. The "singleton effect" is given by a "caching" inside method TransliterationImpl::loadBody(): when multiple instances of the same class are requested in a row, the first one is returned all the times. This does not seem right IMHO. Removing that part allows each TransliterationWrapper instance to have its own Transliteration_caseignore instance. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 --- Comment #44 from Arrigo Marchiori --- Method com::sun::star::i18n::Transliteration_caseignore::loadModule() is used to load "modules" for processing text. There seems to be only one instance of Transliteration_caseignore for the whole program (a "singleton"). Such instance is accessed via a utl::TransliterationWrapper instance. There are several place where a TransliterationWrapper is constructed: 1- ScGlobal::GetpTransliteration() -- specific for OpenOffice Calc. The object is created with module TransliterationModules_IGNORE_CASE 2- vcl::I18nHelper::ImplGetTransliterationWrapper(). The object is created with modules TransliterationModules_IGNORE_CASE and TransliterationModules_IGNORE_WIDTH. 3- OnDemandTransliterationWrapper::get(). The object is created with the modules passed to the OnDemandTransliterationWrapper constructor. In fact, it also has a zero-parameter constructor, and the modules are passed to the OnDemandTransliterationWrapper::init() method. This happens in SvNumberFormatter::ImpConstruct. The IGNORE_CASE is the only module requested. In fact, construction no. 2- instructs the singleton instance of Transliteration_caseignore to load the IGNORE_WIDTH module alongside the IGNORE_CASE. This construction, in one case I could observe, is requested by method ComboBox::ImplUpdateFloatSelection(). This looks like something that could happen at any time. Construction no. 1- and 3- are equivalent, because they request the same single module IGNORE_CASE. Construction no. 2- is frequently happening after the test document is loaded, and before it is saved, therefore invalidating the in-memory list of database ranges. I believe that fixing this problem will consist of having both IGNORE_CASE and IGNORE_WIDTH indicated in all attempts to construct a TransliterationWrapper. I will try to follow this path and report here my results. -- You are receiving this mail because: You are the assignee for the issue.
[Issue 126680] Unable to save a document in ODS with builds using non-Latin alphabets, due to changes of transliteration rules at runtime
https://bz.apache.org/ooo/show_bug.cgi?id=126680 Arrigo Marchiori changed: What|Removed |Added OS|Windows 7 |All Summary|Unable to save a document |Unable to save a document |in ODS with builds using|in ODS with builds using |non-Latin alphabets |non-Latin alphabets, due to ||changes of transliteration ||rules at runtime --- Comment #43 from Arrigo Marchiori --- Concentrating on the cyrillic build: method Transliteration_caseignore::compare() is responsible for comparing strings. The cyrillic word starts with 'б', that is the Unicode code point U+0431, "Cyrillic small letter Be". The first letter of the compared ASCII string is 'S'. When the file is _loaded_ this 'S' is represented with code point U+0073, "Latin small letter S". When the file is _saved_ the same 'S' is represented with code point U+ff53, "Fullwidth Latin small letter S". These two codepoints are respectively ``smaller'' and ``bigger'' than U+0431 and this gives the problem: the database ranges, in memory, are not sorted correctly any more. If we close and reopen the same file, the second time 'S' is again represented as U+ff53 _at loading time_. This allows the save to succeed. When I wrote ``represented'' above, I meant the value returned by: casefolding::getNextChar(). We must understand why the behavior of this method changes at some point during AOO execution. -- You are receiving this mail because: You are the assignee for the issue.
