[Libreoffice-ux-advise] [Bug 152712] Support setting style attributes relative to parent style
https://bugs.documentfoundation.org/show_bug.cgi?id=152712 --- Comment #9 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #8) > Do you know the "Document Theme" (available in the sidebar if experimental > features is on)? Not what you are looking for but improvements there make > more sense. No, and - I didn't realize there was a toggle for experimental features. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152661] "Hybrid PDF" must share embedded media between the ODT and the proper PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=152661 --- Comment #6 from Eyal Rozenberg --- (In reply to V Stuart Foote from comment #5) > The current two-way filters are efficient and functional--suited to our > needs for Hybrid PDF. They're not efficient - they about-double the amount of space necessary, when the embedded media is significantly larger than the rest of the document. Hence this bug. As for the rest of your comment... Right now, the PDF import filter, upon noticing a PDF is a "hybrid PDF" - e.g. by some field/tag in the trailer or xref table, I guess - chucks all of the PDF and keeps the embedded ODF document. So, there's already some parsing going on which results in a coherent ODF - although, granted, it's limited. Also, the PDF export filter (whether it's a hybrid PDF or not) already packs elements into multiple PDF object streams and creates xref entries for them. The change I'm proposing is that media references in the ODF saying "the PNG file named foo.png packed into this ODF", we will have references saying, oh, maybe something like "the indirect object 12345 foopng within the PDF this ODF is in". Indeed, this means there will need to be more parsing. But - that's nothing compared to the amount of work done when importing MSO files! It's basically at the level of complexity of a regexp application. > However, refactoring PDF export filter to reliably embed ODF canvas > internals as PDF object streams I don't think I suggested doing that. I hope my last couple of paragraphs illustrate what I mean > would be non-performant--which elements go > where? While the likely necessary use of /ActualText (as for bug 117428) > tagging for *all* text runs I'm only talking about media such as images, sound, video and arbitrary binary files. I really think you've misunderstood my suggestions. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152661] "Hybrid PDF" must share embedded media between the ODT and the proper PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=152661 --- Comment #5 from V Stuart Foote --- You are asking for PDF filter export to pack ODF compliant elements into a PDF Object stream and individual xref entries. And to provide reverse PDF filter import to parse those same Object streams back into a coherent ODF ready XML. The current approach is a single export stream embedding a single ODF compliant document as a PDF Object stream --the LibreOffice "Hybrid PDF". That is matched by a filter import stream that reads the PDF xref table, recognizes the entry for LO generated source ODF, and selectively parses that ODF stream rather than the full PDF. The current two-way filters are efficient and functional--suited to our needs for Hybrid PDF. As noted in see also bug 95328 to refactor export/import filters and make the ODF a PDF "attachment" might make sense to allow other PDF viewers to recognize the attached ODF. However, refactoring PDF export filter to reliably embed ODF canvas internals as PDF object streams would be non-performant--which elements go where? While the likely necessary use of /ActualText (as for bug 117428) tagging for *all* text runs would negate any potential size reduction of embedding ODF elements as PDF object streams. And then there would be filter requirements to be able to roundtrip--rather than a single fully ODF compliant source document, we would have to parse the entire PDF xref table, identify where each PDF Object needs to be placed (and on which page) individually extract and hold, and then reassemble in to some semblance of the original source ODF. It could be done, obviously--but it is not advantageous to the project in any sense to do so! Not an imperative, certainly not worth the dev effort refactoring both PDF filters would require. So again, NO! -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152661] "Hybrid PDF" must share embedded media between the ODT and the proper PDF
https://bugs.documentfoundation.org/show_bug.cgi?id=152661 Eyal Rozenberg changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Eyal Rozenberg --- (In reply to Heiko Tietze from comment #3) > While reducing the footprint is desired in general we have to deal with the > standards. And either all PDF reader change their implementation or ODF > relies on the way PDF handles content, if we read embedded data from the > alien format. So this is unfortunately not going to fly. I believe you've misunderstood my suggestion. I'm suggesting for the PDF to not change at all, and be perfectly valid regardless of the ODT tacked on to it. It is the ODT which should be altered, so that instead of referring to media within the ODT, it refers to media that's part of the PDF. If one then saves the opened file to an ODT, it will be saved the "regular" way. At worst, this would require some tweaking of how one refers to media in the ODF format, to cover this use-case. At best - ODF already supports something like this, and it's just a matter of using this support. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 147656] Presenter console default disable
https://bugs.documentfoundation.org/show_bug.cgi?id=147656 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #11 from Heiko Tietze --- Not reproduced, removing UX -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152558] Calc Cell Borders are inconsistent with the drop-down graphic selector. Also, No help page for manual definitions
https://bugs.documentfoundation.org/show_bug.cgi?id=152558 Heiko Tietze changed: What|Removed |Added Status|UNCONFIRMED |NEW CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org, ||olivier.hallot@libreoffice. ||org Keywords|needsUXEval | OS|Windows (All) |All Ever confirmed|0 |1 --- Comment #10 from Heiko Tietze --- Looks like we cannot achieve symmetry and a large number of options. Regina, what do you think? The initial bug report was about the preview in the drop down. Valid issue => NEW The help/documentation aspect would be better handled in a different topic (as a rule of thumb, submitting a patch should resolve a ticket - and help related patches rarely include C++ code). -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152712] Support setting style attributes relative to parent style
https://bugs.documentfoundation.org/show_bug.cgi?id=152712 --- Comment #8 from Heiko Tietze --- Do you know the "Document Theme" (available in the sidebar if experimental features is on)? Not what you are looking for but improvements there make more sense. -- You are receiving this mail because: You are on the CC list for the bug.
[Libreoffice-ux-advise] [Bug 152655] Introduce a Slide/Page style category in Impress
https://bugs.documentfoundation.org/show_bug.cgi?id=152655 Heiko Tietze changed: What|Removed |Added Keywords|needsUXEval | CC|libreoffice-ux-advise@lists |heiko.tietze@documentfounda |.freedesktop.org|tion.org --- Comment #6 from Heiko Tietze --- (In reply to Eyal Rozenberg from comment #5) > PS - Where is "everywhere"? We're talking about Impress and Draw. Microsoft Office, for example. Any application using ODF. -- You are receiving this mail because: You are on the CC list for the bug.
