Bug 162700 - Export to HTML doesn't export embedded ODF files
Summary: Export to HTML doesn't export embedded ODF files
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.2.3 release
Hardware: x86-64 (AMD64) Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: (X)HTML-Export
  Show dependency treegraph
 
Reported: 2024-08-29 21:48 UTC by Jens Schwartz
Modified: 2024-09-09 07:43 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
the ODT Master including the embedded Slave (161.40 KB, application/vnd.oasis.opendocument.text)
2024-08-29 21:49 UTC, Jens Schwartz
Details
the export to HTML (zipped) of the Master (82.26 KB, application/x-zip-compressed)
2024-08-29 21:50 UTC, Jens Schwartz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Schwartz 2024-08-29 21:48:22 UTC
Description:
Having a LibreOffice Writer document which includes pictures as well as an .odt file (embedded, not linked)

When I export the document to HTML the HTML file gets created along with the embedded pictures. But the embedded ODT doesn't get exorted (and represented by a link inside the main HTML).

Not tested yet: I believe this is the behavior for all binaries aside known picture file formats.

Steps to Reproduce:
1. create an ODT (Master)
2. embed another ODT (Slave) (OLE, as Icon, NOT as link)
3. export the Master to HTML

Actual Results:
the embedded ODT (Slave) doesn't get exported altough it's stored in Master's package

Expected Results:
the embedded ODT (Slave) should have been exported and linked inside the Master HTML


Reproducible: Always


User Profile Reset: No

Additional Info:
I'm pretty sure, resetting the profile wouldn't change a thing since In tested this on multiple PCs running different operating systems ^^

Added a picture to the example Master to show the difference.
Comment 1 Jens Schwartz 2024-08-29 21:49:39 UTC
Created attachment 196103 [details]
the ODT Master including the embedded Slave
Comment 2 Jens Schwartz 2024-08-29 21:50:42 UTC
Created attachment 196104 [details]
the export to HTML (zipped) of the Master
Comment 3 Buovjaga 2024-08-30 08:22:48 UTC
A private message was relayed to me saying you can create design drafts for this. Feel free to attach any such proposals to this report.
Comment 4 Jens Schwartz 2024-09-08 20:24:43 UTC
Hi all,

did some more detailed testing and found the whole topic to be much more complicated. ^^

Since there's a limitation coming with OLE anyway, I further focus on OLE objects only.
(From my POV it would be nice to be able to just embed any file type by a simple way. Parsing in any way is not required to just "collect" resources into an ODF.)

About the initial report...

Whenever an object gets inserted via OLE it is stored in the package.
Whenever a picture is (displayed) in the document it is stored in the package.

Once you export the ODF to HTML the pictures get saved separately (exported from the package) and the HTML get the required <img> tags. This img tags are already getting created for placeolder icon for embedded object.

I recommend to just also export all OLE Objects embedded "as icon" as well + create links (href) inside the HTML.

This should be done regardless the actual file type.

How it should work:

1 - Have an ODT (or ODF at all) including displayed images and files embedded (not linked) as symbol.
2 - Save as HTML
3 - This creates a HTML 
+ the image files (as for now)
+ stores all the OLE embedded separately to ther original file types
+ updates the links within the HTML to point on this exported files

Hope, this was some kind of comprehensible. ^^
Comment 5 Heiko Tietze 2024-09-09 07:43:45 UTC
(In reply to Jens Schwartz from comment #4)
> I recommend to just also export all OLE Objects embedded "as icon" as well +
> create links (href) inside the HTML.
Although using HTML to share formatted text (odt) makes not much sense, the embedded objects should not get lost. And the proposal sounds reasonable.