This may not be a bug but it should be documented here. I was inspired by what Justin wrote in bug 143578 and read this URL and took his sample OXT configuration extension and was able to extend it. I added Expert configuration, Macro, Outline and it all worked with the extension (to be added via unopkg). I also tried to remove Asian language and Complex text layout but it only half worked. I couldn't remove Asian language in common.xcu with: <node oor:name="I18N"> <node oor:name="CJK"> <prop oor:name="AsianTypography" oor:type="xs:boolean" oor:finalized="false" > <value>false</value> </prop> </node> </node> Contrary to Asian, CTL removal seems to work when set in the same I18N node with: <node oor:name="CTL"> <prop oor:name="CTLFont" oor:type="xs:boolean" oor:finalized="false" > <value>false</value> </prop> </node> I checked xmldiff from new RegistryModifications.xcu and one after I manually turned off Asian and CTL. It has: <item> <prop oor:name="AsianTypography" oor:op="fuse"/> </item> Where is "false"? What is "fuse"? It also added many CJK and CTL related settings whose default value is "false" or "0" anyway, or is "true" for Ignore property. So, question or bug is: why I coudn't set false to AsianTypography via this modification and turn off Asian language support?
The idea here is that Options - Language Settings - Languages - Default Languages for Documents should be turned off for CJK and CTL. Based on my testing, it looks like EVERY ONE of these needs to be set false in order for the "enabled" flag to be off <node oor:name="CJK"> <prop oor:name="CJKFont" oor:type="xs:boolean"> <value>false</value> </prop> <prop oor:name="AsianTypography" oor:type="xs:boolean"> <value>false</value> </prop> <prop oor:name="ChangeCaseMap" oor:type="xs:boolean"> <value>false</value> </prop> <prop oor:name="DoubleLines" oor:type="xs:boolean"> <value>false</value> </prop> <prop oor:name="EmphasisMarks" oor:type="xs:boolean"> <value>false</value> </prop> <prop oor:name="JapaneseFind" oor:type="xs:boolean"> <value>false</value> </prop> <prop oor:name="Ruby" oor:type="xs:boolean"> <value>false</value> </prop> <prop oor:name="VerticalCallOut" oor:type="xs:boolean"> <value>false</value> </prop> <prop oor:name="VerticalText" oor:type="xs:boolean"> <value>false</value> </prop> </node>
Thanks. Solution works for empty profile (or for later change from default checked to unchecked). It seems to me that it doesn't work if it was manually unchecked and then checked again. Neither for CJK nor CTL. Not sure if it's related tot oor:type and oor:op="fuse", as you noted in OXT guide, Step 2c. But it doesn't work for me also if oor:op="fuse" used. Please mark New if that should be changed or NotABug if not. Note: I stumbled upon useful wiki: https://wiki.openoffice.org/wiki/OOR-document-format It should be transferred to LO Wiki.
I kindly ask you to explain one more issue here and in your guide, which is not this bug but I had a problem with it. In Common I tried with this to set Macro Security to Medium but it didn't work, seems some issue with long type: <node oor:name="Security"> <node oor:name="Scripting"> <prop oor:name="MacroSecurityLevel" oor:type="xs:long" oor:finalized="false" > <value>1</value> </prop> </node> </node>
(In reply to Timur from comment #2) > It seems to me that it doesn't work if it was manually unchecked and then > checked again. Neither for CJK nor CTL. Yes. These are only "suggestions" in absence of a specified setting. If you want your policy to "override/enforce" then you need to set finalized = true > Please mark New if that should be changed or NotABug if not. I only know this stuff based on trial and error, not on what OUGHT to be.
(In reply to Timur from comment #3) > In Common I tried with this to set Macro Security to Medium but it didn't > work, seems some issue with long type: It works with "int" (again discovered by trial and error). > <prop oor:name="MacroSecurityLevel" oor:type="xs:int"
Hi Stephan This is of lowest priority, but it takes someone knowledgeable to decide. I noticed your contribution at OpenOffice.org Registry Format so I hope you can make a comment and set status for this "Asian language setting". Could you also please explain something that could be added to https://wiki.documentfoundation.org/Development/Extension_Development: - Why oor:type="xs:int" must be used where setting in Expert Configuration shows "long" as Type; - Is oor:type setting in OXT important? Can it be left out? - Why RegistryModifications has no oor:type setting but it has oor:op="fuse"?
(In reply to Timur from comment #6) > - Why oor:type="xs:int" must be used where setting in Expert Configuration > shows "long" as Type; There used to be <http://util.openoffice.org/common/configuration/oor-document-format.html> "OpenOffice.org Registry Format (OOR)" describing the registry format, but that has apparently been lost to history. I find what looks like a faithful copy of that document at <https://people.freedesktop.org/~vmiklos/2013/oor-document-format.html>, though. The registry uses the XML Schema xs:int type for 32-bit integers. The expert configuration presumably naively uses the name of the corresponding UNO type LONG instead. I think cleaning up the terminology used by the expert configuration to better match the XML Schema terminology (rather than the UNO terminology) might be worth an enhancement request. > - Is oor:type setting in OXT important? Can it be left out? Without actually looking into the code now, I /think/ it can be left out in the registry update format for properties that are not of type oor:any. > - Why RegistryModifications has no oor:type setting but it has oor:op="fuse"? I do not understand that unspecific "RegistryModifications has no oor:type setting" claim. For the meaning of oor:op="fuse", see the document mentioned above.
I don't see any reason for this bug report to exist. There is no requirement that a single registry entry be able to control a UI checkbox. All information needed to enable Asian Language has been provided in comment 1 / comment 4, so I'll mark it as fixed.