Description: Musical symbols in question: sharp ♯ U+226F double sharp 𝄪 U+1D12A flat ♭ U+266D double flat 𝄫 U+1D12B After a recent update, probably one that changed the default font from Nimbus to Noto, the design of each symbol in the .ODT file may appear inconsistent throughout different grammatical periods, and in the exported .PDF unnacceptably incoherent with the content typed in the .ODT. Note these four musical symbols may belong to two different unicode sets of characters. Steps to Reproduce: 1. Enter all the musical symbols in both Nimbus and Noto fonts: A♯ A𝄪 A♭ A𝄫 2. Export to PDF 3. Check if in both fonts the output is musically acceptable Actual Results: 1) In either Nimbus or Noto, sometimes the musical symbols retain the old design, more thin and fit do the characters but not so visible and elegant as now; copying them and pasting them AFTER a period '.' changes them to their new design, but copying the new design symbols to BEFORE that same period just make them appear with the old design again; The old design ocurrences do not appear correctly in the exported PDF: 2) In Nimbus, not Noto, the old design occurrences of double sharp or double flat at the ODT document appear as a single, non-double, sharp or flat printed in the PDF, and when copyed and pasted elsewhere come as single, not double as they were in the ODT; the old design occurrences of single sharp or flat do not appear as printed in the PDF at all, only when the space where they should appear is copyed and pasted elsewhere, when they appear as the single accident which they are. 3) In Noto, the old design occurrences of the double flat in ODT document appear as old design in the exported PDF, while the old design of the flat in the .ODT appears as a new design in the .PDF Expected Results: Draw with musical precision the different quantities of every musical accident that was typed. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 2; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: pt-BR (pt_BR.UTF-8); UI: pt-BR 24.8.4-1 Calc: threaded
Can you attach a demo document in order to test it? Thanks
Also, in some occurrences the musical symbols in the new design, more thick and elegant than the old design, appear to occupy a good portion of the space following them, making it to appear that there is virtually no space between words; in other occurrences, they remain thick but the space after them is complete, allowing a good reader experience. Now this last issue of space was gone when running "libreoffice --safe-mode"; the others remained exactly as they were.
Created attachment 198392 [details] example ODT From a paragraph with both occurrences of old and new design, removing unneccessary words, when a character with the new design reached the line of the characters with the old design, all the new design occurrences in that period were reverted to old design occurrences NOW the exported .PDF from the example .ODT shows only old design occurrences, albeit in the .ODT the new design occurrences show up. I took screenshots just in case.
Created attachment 198393 [details] appearance of example .ODT
Created attachment 198394 [details] WRONG_UPDATED_FILE
Created attachment 198395 [details] example exported .PDF
Created attachment 198396 [details] appearance of example exported .PDF
Note: While removing unneccessary words, I accidentally DID NOT remove some "A M" without accidents from the paragraph in Nimbus Roman. It is not the case that they just disappeared, it is that they were not there in the first place.
Created attachment 198397 [details] Wrong output in PDF from the original .ODT file (Nimbus Roman)
Real life context. Musical accidentals are elementar parts of musical theory. Any mistake on them messes up stuff; you can get a zero or a boo, which may imply this bug is a blocker. https://en.wikipedia.org/wiki/Accidental_(music)
Trying the original .ODT file in another machine, with a fresh installation of 24.8 through snap in Ubuntu, after purging every libreoffice package with apt, the issue of accidentals showing up wrong in the exported .PDF remains the same as in "wrong output in PDF...." above; pasting the text from the .PDF to a .ODT produces the same "double flat in .ODT -> single flat in .PDF with a new design, more round (not more thick) -> single flat in pasted text" and "invisible single in .PDF -> visible single in pasted text" anomaly. Only, there is no "new design" instance in those paragraphs in the original .ODT, only in the .PDF. The example .ODT file provided opens with both old and new design instances and exports to PDF without any new design instance, only the old ones. Pasting the text to the example .ODT produces the same old and new design instances as there already was in the example .ODT file, without any discrepancy regarding double flat characters or any other.
Check the PDF export settings dialog for the "PDF Version" dropbox, yours looks to be defaulting to a PDF/A so check for font embedding issues--but the simple PDF 1.7 should suffice.
(In reply to V Stuart Foote from comment #12) > Check the PDF export settings dialog for the "PDF Version" dropbox, yours > looks to be defaulting to a PDF/A so check for font embedding issues--but > the simple PDF 1.7 should suffice. 1) in the first machine that PDF/A option was enabled, but not in the second machine. In "both both" cases ― enabled and disabled the option, in both machines ― the exporting to PDF of the original .ODT files produce the double->single anomaly. 2) After reducing the original .ODT file to a new document consisting only of the single page where the issue happens when exporting to .PDF, and then exporting that single page document to a .PDF, the issue doesn't happen. 3) When exporting from the original .ODT file: a) ONLY that single page (~20th in the writer document), the issue doesn't happen; b) from page 14 or earlier to 23, the issue still happens; c) from page 15 or latter to 23, the issue doesn't happen anymore.
(In reply to HeartLetter from comment #13) > a) ONLY that single page (~20th in the writer document), the issue doesn't read: 23th in the writer document, the last one in each range of exported pages
To be clear, is this about "A♭", A flat? I notice that both with Noto Serif and Nimbus Roman in your example ODT file, there are two different renderings in the two lines even though the font is the same. I checked that the Unicode character is U+266D for both.
Font fallback at work? And an user controlled mixing of DF and Style authoring. With attachment 198392 [details], if I use The Tools -> Options -> Font "Replacement table" for Nimbus Roman (not present on my system) with say Bravura Text, no issue-- produces reasonable fidelity on screen and exported to PDF with the substituted font. So our font substitution is an option. Alternatively, removing the Direct Formatting for entire document, and adjusting the Body text to use Noto Serif (or some other font with better Unicode coverage of both the 'Miscellaneous Symbols' and the 'Musical Symbols' Unicode block like Bravura Text) works better. Of course Bravura Text is a Sans styled font, and it's support for SMuFL means it has a whole lot of Unicode PUA glyphs that are not going to be "functional" in LibreOffice for notation. But the core Unicode seems fine. No missing glyphs between onscreen and exported to PDF.
(In reply to V Stuart Foote from comment #16) > Alternatively, removing the Direct Formatting for entire document, and > adjusting the Body text to use Noto Serif (or some other font with better > Unicode coverage of both the 'Miscellaneous Symbols' and the 'Musical > Symbols' Unicode block like Bravura Text) works better. I just went back to that file to change to Noto Serif and found out that since April 16th (I'm in Parabola based off Arch GNU/Linux, rolling release distros), when I exported the whole document to PDF, ALL OLE OBJECTS ― formulae and graphics ― were messed up back then, both in Writer and in the exported PDF: 1) The first formula could not be edited by pressing "enter" or double-clicking after selecting them ― I had to replace it with a copy from another file in order to be able to edit it. 2) All other OLE objects appear dephased in some way, any FAR POSTERIOR object file being drawed both in .ODT and .PDF instead of the present object and within the shape of the present object. How to fix that? There are more than 200 objects there.
Created attachment 202154 [details] Correct text appearing in ODT within a table with Noto Serif Condensed Newly created ODT document with ~26 pages.
Created attachment 202155 [details] No characters appearing in PDF within a table with Noto Serif Condensed Newly created ODT, exported to PDF, ~26 pp.
(In reply to HeartLetter from comment #17) > I just went back to that file to change to Noto Serif and found out that > since April 16th (I'm in Parabola based off Arch GNU/Linux, rolling release > distros), when I exported the whole document to PDF, ALL OLE OBJECTS ― > formulae and graphics ― were messed up back then, both in Writer and in the > exported PDF: > > 1) The first formula could not be edited by pressing "enter" or > double-clicking after selecting them ― I had to replace it with a copy from > another file in order to be able to edit it. > > 2) All other OLE objects appear dephased in some way, any FAR POSTERIOR > object file being drawed both in .ODT and .PDF instead of the present object > and within the shape of the present object. > > How to fix that? There are more than 200 objects there. Sounds like something to create a different report for. (In reply to HeartLetter from comment #18) > Created attachment 202154 [details] > Correct text appearing in ODT within a table with Noto Serif Condensed > > Newly created ODT document with ~26 pages. Again, seems like something different from your original report. Please create a new report with an example ODT file.
Created attachment 202171 [details] I edited to screenshot this from the ODT; now both lines are bugged in PDF
Created attachment 202172 [details] Those lines in the exported PDF. (In reply to HeartLetter from comment #0) > 2) In Nimbus, not Noto, the old design occurrences of double sharp or double > flat at the ODT document appear as a single, non-double, sharp or flat > printed in the PDF, and when copyed and pasted elsewhere come as single, not > double as they were in the ODT; the old design occurrences of single sharp > or flat do not appear as printed in the PDF at all, only when the space > where they should appear is copyed and pasted elsewhere, when they appear as > the single accident which they are. Now it is happening with Noto also. The only difference is there are some "tofu", against the Noto purpose of having no-tofu.
(In reply to Buovjaga from comment #20) > (In reply to HeartLetter from comment #17) > > How to fix that? There are more than 200 objects there. > Sounds like something to create a different report for. Yes. At least perhaps. I would need to try a Master Document if there is some limitation in resource-managing for single documents. > (In reply to HeartLetter from comment #18) > > Created attachment 202154 [details] > > Correct text appearing in ODT within a table with Noto Serif Condensed > > Newly created ODT document with ~26 pages. > Again, seems like something different from your original report. Please > create a new report with an example ODT file. No. Exactly the same issue, as I quoted, now happening worse with Noto also. Cleaning Cleaning Direct Formatting in the whole document where the issue happens: the issue STILL happens. Exporting only the page of that document, 15th in the ODT, where the issue happened in the PDF: the issue does NOT happen anymore in the PDF. It seems like a resource management issue. I have just tested ALL the following in another ODT newly created for testing (libreoffice-fresh 25.2.5-1), and NONE make the issue to happen, even though both ODT and PDF have >30 pages. 1) Almost full-page tables, not overlapping, in more than >30 pages: the issue does NOT happen. 2) Tables overlapping pages, more than >30 pages: the issue does NOT happen 2.a) with a OOLilyPond musical snippet (SVG + LilyPond code): the issue does NOT happen 2.a+b) with titles between the tables: the issue does NOT happen 2.a+b+c) generating a Summary: the issue does NOT happen 2. a+b+c+d) adding a OLE formula: the issue does NOT happen 2. a+b+c+d+e) converting the first page in a cover page: the issue does NOT happen 2. ...e+f) adding some page without content and converting it in a cover page: the issue does NOT happen 2. ...f+g) just adding a footer for the standard page style: the issue does NOT happen 2. ...g+h) changing the setting to allow different content in left and right pages: NOT 2. ...h+i) putting page numbers in both left-page and right-page footers: NOT 2. ...i+j) setting right-footer and left-footer styles: NOT 2. ...j+k) directly formatting some words with Ctrl+i for italic: NOT 2. ...k+l) adding text in the "Body" style (Ctrl+0): NOT 2. ...l+m) adding text in the Quotation style: NOT 2. ...m+n) changing properties of Body and Quotation style: NOT 2. ...n+o) changing properties of Table content style: NOT 2. ...o+p) loading some style from model, "styles -> Modern": NOT [I may have done this '2.p)' before the rest of the other document in '3', in order to avoid bold headers; but it only works for that before every other setting] 2. ...p+q) adding a document title before the summary: NOT 2. ...q+r) changing properties of the default page style: NOT 2. ...r+s) including the musical symbols ♯ 𝄪 ♭ 𝄫 in all headers and updating the summary: NOT 2. ...s+t) placing OOLy SVGs within tables: NOT 2. ...t+u) setting borders on tables: NOT 2. ...u+v) directly formatting in versalettes (Ctrl+Shift+k) some words before the tables: NOT 2. ...v+w) putting the symbols ♯ 𝄪 ♭ 𝄫 within the tables: NOT 2. ...w+y) adding the greek alphabet Α α, Β β, Γ γ, Δ δ, Ε ε, Ζ ζ, Η η, Θ θ, Ι ι, Κ κ, Λ λ, Μ μ, Ν ν, Ξ ξ, Ο ο, Π π, Ρ ρ, Σ σ ς, Τ τ, Υ υ, Φ φ, Χ χ, Ψ ψ, Ω ω before every table: NOT 2. ...y+z) adding letters from the greek alphabet to all headers: NOT
Created attachment 202501 [details] ODT x PDF in new libreoffice-fresh release 25.8.0-1 Monitoring it: the issue just got worse with libreoffice-fresh 25.8.0-1; in the first row of the table, now some letters before the musical accidents appear in the wrong places also.