octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #64349] [octave forge] (io) Writing into exist


From: Philip Nienhuis
Subject: [Octave-bug-tracker] [bug #64349] [octave forge] (io) Writing into existing xlsx file fails because "dcterms:created" missing
Date: Sat, 1 Jul 2023 09:18:03 -0400 (EDT)

Update of bug #64349 (project octave):

                  Status:               Need Info => In Progress            
             Assigned to:                    None => philipnienhuis         
                 Release: 8.2.0 8.X Series Bug Fix Release  => other          
       

    _______________________________________________________

Follow-up Comment #9:

Try with attached  __OCT_oct2xlsx__.m  and report back if it fixes the issue
for you.

Use the following commands to find out where it lives (but I saw in comment #0
that you already know how to find it):
cd (strrep (which ("oct2xls"), "oct2xls.m", ""))
cd private

Initially I had the same fix in mind as your patch, but after perusing the
ECMA docs (OOXML specs) and
https://www.dublincore.org/specifications/dublin-core/dcmi-terms/ (where the
dcterms nodes are outlined) I conclude the dcterms:created node isn't really
required; although the website says it is advised to specify it. Maybe
Spire.XLS can update their .xlsx creation process but it seems strictly
speaking they wouldn't need to.

So my current fix merely checks *if* the dcterms:created node is present at
all and if so, only then adapts the date. If not, it just skips this step.
That leaves the file w/o info on creation date/time but as you found out
that's not a showstopper for at least Excel; LibreOffice also swallows it.
That stanza in  __OCT_oct2xlsx__.m  was originally only introduced for use
when creating .xlsx files. I think it may be better adapt it to only touch the
node when an .xlsx file is overwritten. I may do so in a later stage but as it
stands this whole bookkeeping part of  __OCT_oct2xlsx__.m  is already
complicated enough. I there's no often used SW Out There that really needs
this info I'd rather keep it simple.

So the next weeks I'll ponder about which patch to apply: yours (faking a
creation date) or mine (just leaving the creation date missing) :-)


(file #54905)

    _______________________________________________________

Additional Item Attachment:

File name: __OCT_oct2xlsx__.m             Size:21 KB
    <https://file.savannah.gnu.org/file/__OCT_oct2xlsx__.m?file_id=54905>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64349>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]