Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Product:||App Dev||Reporter:||pmartino <pierre.martineau>|
|Component:||api||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Version:||3.3.0 or older (OOo)||Keywords:||oooqa|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description pmartino 2004-04-23 12:50:11 UTC
in com.sun.star.text.BibliographyDataField the BIBLIOGRAPHIC_TYPE is misspelled BIBILIOGRAPHIC_TYPE (additional I at the fourth position) This both appear in the "IDL reference" and in the program. I used python to access the bibliographic textfields in a text : import uno # get the uno component context from the PyUNO runtime localContext = uno.getComponentContext() # create the UnoUrlResolver resolver=localContext.ServiceManager.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", localContext ) # connect to the running office ctx = resolver.resolve("uno:socket,host=localhost,port=8100;urp;StarOffice.ComponentContext" ) smgr = ctx.ServiceManager # get the central desktop object desktop = smgr.createInstanceWithContext("com.sun.star.frame.Desktop",ctx) # access the current writer document model = desktop.getCurrentComponent() # get the list of ref refs = model.getTextFields().createEnumeration() # get the first ref ref = refs.nextElement() # print the BibliographicType field (=1) print ref.Fields.Name The result is the unicode string "BibiliographicType" This is not a real problem when I want to modify the reference since I can use in my code the explicit value of 1 and it should not break in the future. But when I want to introduce a new reference in the text I have to put the correct string in the Fields.Name that is "BibiliographicType" (but was in OOo previous versions "BibliographicType")
Comment 1 ooo 2004-04-26 13:36:27 UTC
forwarding to responsible developer
Comment 2 thomas.lange 2004-06-07 12:12:00 UTC
TL->SW: Please choose target and priority as it seems fit to you.
Comment 3 thomas.lange 2004-06-07 12:13:11 UTC
Comment 4 stephan.wunderlich 2004-06-09 15:59:47 UTC
SW->TL: I couldn't find a version that doesn't have this typo, so I'm not sure if we should change it and so possible break programs/scripts which already exist. I set it to OOoLater for now.
Comment 5 stephan.wunderlich 2004-06-10 14:18:22 UTC
forgot to reassign
Comment 6 christianjunker 2005-09-02 13:25:40 UTC
I counted about 20 affected, but as said there is also the problem of backwards-compatibility, mainly with older scripts. I am afraid this really might take a lot of work, the ideal case would be if both strings would be accepted and what we can do here is adding another const BIBLIOGRAPHIC_TYPE which is perfectly valid for constant groups but not for true enums (lucky that this is not affecting an enum). Another option of properly fixing this, is to just make a note in the idl file, explicitly emphasizing that an BIBILLIOGRAPHIC_TYPE must be written so (with an additional i). cyb->tl: What do you think ?
Comment 7 christianjunker 2005-09-02 13:27:01 UTC
adding myself to cc.
Comment 8 christianjunker 2005-09-02 13:46:53 UTC
I just took another look, and found that 3 files are responsible for the .name attribute "BibiliographicType" which could easily be changed to "BibliographicType" which does not really do anything about the idl constant type. The three files are in sw and xml modules, named authfld.cxx, txtflde.cxx, txtfldi.cxx . So if we just want to change the .name attribute string to the correct one, then we could do this by fixing those three files. However, this raises another issue again: Slight incosistency, idl type is BIBI... and field is named Bibl...
Comment 9 thomas.lange 2005-09-05 07:59:37 UTC
That's correct the type needs to be corrected. That is because of compatibility a new one with correct typography and same value has to be added and the original one is to be marked deprecated.
Comment 10 christianjunker 2005-09-11 01:59:55 UTC
cyb->tl: Are you working on it, or is there space for a volunteer's contribution ;)?
Comment 11 thomas.lange 2005-09-12 08:34:59 UTC
According to the current target it is not yet on my schedule. So anyone please feel free.