Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Date field in footer is displayed in time format|
|Component:||open-import||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||issues, mnagashree, sven.jacobi, yba|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:||76612|
Description Unknown 2004-11-17 12:30:41 UTC
In a presentation created in Powerpoint and imported into OOo 1.9m60, the date field in the footer of slide 2 of the attached presentation changes after import and is displayed in a time format.
Comment 2 nagashree 2005-01-04 11:23:46 UTC
I am unable to replicate the issue on OpenOffice 1.9.62 and OpenOffice 1.9.65
Comment 3 Unknown 2005-01-04 12:08:41 UTC
The problem still exists in 1.9m65. take a close look at slide 2 or 3, bottom left corner of the slide. Time is displayed instead of date. Please see attached screenshot.
Comment 5 nagashree 2005-01-04 12:40:41 UTC
Confirming the issue
Comment 6 nagashree 2005-01-04 12:47:18 UTC
But the slide show run using Power point even has the same effect. I am here by attaching the 2 screen shots of slide 2, one when viewed using MS power point and the other OpenOffice 1.9.65
Comment 7 nagashree 2005-01-04 12:50:51 UTC
Created attachment 21041 [details] Screen shot attached when viewed from MS power point
Comment 8 nagashree 2005-01-04 12:54:16 UTC
Created attachment 21042 [details] Screen shot attached when viewed from OpenOffice 1.9.65
Comment 9 alan 2006-10-09 14:24:00 UTC
In the attached presentation, datetest.ppt, the problem is clear. Whenever a date/time format in PPT has the "Update Automatically" option checked, the format becomes corrupted. If it is not checked, the date/time is diplayed correctly.
Comment 10 alan 2006-10-09 14:26:46 UTC
Created attachment 39649 [details] See slide 2, which has formats with and without "Update Automatically"
Comment 12 alan 2006-10-09 14:29:16 UTC
Created attachment 39651 [details] Date/times in Impress - "Update Automatically" messes up format
Comment 13 alan 2006-10-10 12:38:18 UTC
Created attachment 39663 [details] Same as above - mime type corrected
Comment 14 alan 2006-10-10 13:22:53 UTC
ayaniger -> sj: I've gathered some data about this issue, and I would appreciate your help in interpreting the data. In the version of PowerPoint on which the sample presentation, datetest.ppt, was created, there are 13 English date/time formats and 6 Hebrew date/time formats. In datetest.ppt, the formats are listed on the slide in the same order as they appear in PowerPoint's “choose date format” dialog box. Of PowerPoint's English formats the first 7 have the date alone, the next 2 have both date and time, and the last 4 have the time alone. When datetest.ppt is imported into OOo, the date/time format value is passed as “nVal” to the function PPTFieldEntry::SetDateTime in svx/source/svdraw/svdfppt.cxx. If the formats are in English, the value of nVal corresponds to the format's position in the PowerPoint “choose date format” dialog box. That is, the first value in the list of English formats is 0, the second is 1, and so on. If the formats are in Hebrew, for some reason the value of nVal is increased by 7. The first value in the list of Hebrew formats is 7, the next is 8, and so on. This is confusing OOo. It treats the 7, which is supposed to be a Hebrew date format, as if it were number 7 in the list of English formats, which is a combined date/time format. Similarly, 8 is treated as if it were number 8 in the English list. As a result, the last 4 Hebrew formats appear as times instead of dates, since the last 4 entries in the English table are time formats. While “nVal” in SetDateTime tells us the position of the format in the format list, it seems that there must be another setting which tells us which list we are looking at. OOo is apparently ignoring that value. Any direction here would help.
Comment 15 sven.jacobi 2006-10-11 09:48:53 UTC
sj->ayaniger: It seems that the values are language dependent, and this is a little problem, because the language is stored within another structure (aTextSpecInfoAtomInterpreter). To access the correct language the position of the field must correspond to the nCharIdx of the SpecInfoAtom. To create a fix for all languages will be much work I think :-( I hope I could help so far.
Comment 16 alan 2006-10-11 15:05:51 UTC
Created attachment 39691 [details] Changes behavior of SetDateTime based on language
Comment 17 alan 2006-10-11 15:07:45 UTC
ayaniger->sj: I tried using the attached patch, which changes the behavior of SetDateTime, based on the language stored in aTextSpecInfoAtomInterpreter. I implemented this for Hebrew, but other languages can easily be added. I also used an ugly global variable, since this is not final and for the time being, I don't want to change header files and cause massive recompilations. (The patch is a diff with the original 2.0.3 code. I tried a cvs diff, but it just timed out.) One further question: the available date formats in OOo do not match all the available date formats in PowerPoint. With my patch, I'm not getting times instead of dates any more, but the formats aren't always quite right. How can I add additional formats? I saw that there is a file i18npool/source/localedata/data/he_IL.xml which has a list of Date and Time formats for Hebrew, but there are a lot more of them in the XML file than there are in the list I see when I run OOo, and ask for date formats. How is the list of date/time formats created, and what role does he_IL.xml play here?
Comment 18 sven.jacobi 2006-10-11 18:30:45 UTC
sj->ayaniger: Yes, you are right, Impress is having too less date/time formats at the moment. To change this the Impress core needs to be enhanced, as you can see the Writer is providing a different date/time functionality. I am sure the effort to change the current behaviour will be very high.
Comment 19 alan 2007-04-23 11:22:08 UTC
ayaniger->sj: I supplied a patch to this issue for Hebrew, but it seems that any further handling of the issue requires enhancement of the Impress core. Since the issue is no longer in my hands, to whom should I reassign it?
Comment 20 sven.jacobi 2007-04-23 12:17:42 UTC
Oh, I see that your patch hasn|t been integrated, I|ll take over this issue to do this. For further date/time field format enhancements I wrote issue 76612, so this issue can be closed when the patch is integrated.
Comment 21 sven.jacobi 2007-07-23 14:44:09 UTC
Comment 22 sven.jacobi 2007-11-28 14:13:06 UTC