bugged file is 166. while yesterday (previous file version) i left it at 157 and changes made since are less than 1 page. so yeah as i said the doc gets longer. however the style spacing is 0.14 on both old and new versions 
no clue really. maybe it’s a tables issue or a zotero issue.
fortunately i have a new version which is fine (until it isn’t) after the fix provided from @ajlittoz 
PS: @Hrbrgr do you use any plugins such as zotero or similar or the inserted areas where manual?
No any plugins such as zotero, no macro.
was hoping you would say yes so we can pinpoint the origin there or something
That would be my policy too. But just for information: The “jump” is not so big. It is simply a change in numbering to use year.month now. So 24.2 was the direct succession of 7.6.7 as can be seen in the archives
https://downloadarchive.documentfoundation.org/libreoffice/old/
thanks for clarifying! it seemed odd that debian would be 24-7= 14(!) versions back lol. even for debian stable that’s too much heh ^^
Since you use version 7.4, I assume that the “this mark ¶” was in fact more like “
”, i.e. with blue-ish color, not black. So I assume, that what is suspicious is the shape of the pilcrow, which obviously looks like using a different font.
And my suspicious would be, that there is some problem in LibreOffice’s font management, caused by something in your document, which breaks the assignment of fonts to parts. I don’t know what that could be; I don’t know if that is OS-specific or not. But I would definitely check, if that is version-specific - I mean, your
is strange-looking, because new versions sometimes incorporate bugfixes, which sometimes fix bugs 
Of course, since you seem to have it working now, please by all means first finish the time-pressing project. But checking a newer version would still be a reasonable next step. And maybe filing a bug report, too (if you can provide the document, and it still misbehaves in a current version).
correct
correct it seems like a different font, however as i described above the font isn’t actually changing (based on the info provided from the side bar). that’s why it’s a mystery to me. the only indications i have are the length of article (text moving further down than where it was before, tables breaking page even if they didn’t use to, etc) and the presence of the ‘open’ pilcrow.
after looking around in my document what you say here gave me an idea so i think i have a hint. i started this project some months ago but if i recall correctly i have copy-pasted some text from a differently formatted document and i think i used [*]formatted paste to keep some subscripts/superscripts intact. so now if i look at the paragraph style options on the side bar i see there are some additional styles from the MS docx template i was using on the previous project (even though i am not using them now). could it be that the transfer of text brought the styles with and this cross-over is causing the issue? it would explain why i haven’t observed such an issue in previous projects, even though i work with big documents mostly.
another idea would be that as i was working on this project, i opened a different one from a colleague who used MS and doc file types, so maybe the ‘Default Paragraph Style’ i am using got…confused? as @ajlittoz mentioned it’s a shared style so if their default is different it could play a role right? i am just theory-crafting at this point.
if it was a known bug (fixed or not) then i guess someone will state it and i will thank them deeply. until then nothing suggests it’s a version issue. also forgive me if i am being too up-front on this; my background in troubleshooting is in linux forums where normally criticizing OS or versions choices when someone has an issue and asks for help is discouraged unless it’s the only reasonable/proven solution. thanks for understanding 
if this persists i will definitely. may i assume bug reports are only valuable for current versions, correct?
PS: thanks again everyone for your responses and help
[*] edited a misleading typo, thanks @ajlittoz for spotting it
Lol. If I myself knew every time, when changing code, what I fix collaterally. Sometimes I get notifications like ‘bug x was also fixed by this’ after a few years. No matter what the background is. Here checking with an up-to-date version is a good first step.
EDIT 2024-11-18: Just a random day today, just some commit log: Log - 7afb836b23c286eac4605ef4d98cf517f825b8d8 - core - Gitiles
crashtesting: crash on import of rtf exported from forum-en-32886.odt
…
crashtesting: use after free
…
cid#1607833 Overflowed constant
cid#1607905 Data race condition
…
cid#1607919 Overflowed constant
…
tdf#163486: PVS: V614 Uninitialized variable used
Give DocumentEventHolder (aka EventHolder) a key function
… and so on …
All these (and lots of others) are not specific bugfixes; rather, they are something found by the continuous testing (of a large body of test documents, in crashtesting), or static analyzers (Coverity, PVS) - or even just some code reading, and proactive fixing (as in the last case). We don’t really know what specific real-life bugs will be fixed by all these - even the people who actually fix such a code. And of course, when someone else here sees your problem, they are even less likely to know, if it was or wasn’t fixed by some of these - or by hundreds of actual bugfixes, coming every month.
Just to illustrate the point.
amazing 
then i guess in a forum for troubleshooting on one suite it’s easier to say update your version than it is in a forum troubleshooting a group of different flavors of OS lol thanks for sharing this forums pov. then if no one has any other ideas in 1-2 days then the issue can be closed unless it’s better to stay open until debian pushes the update on the stable repo and i try it out and report back. 
We don’t say ‘upgrade’. We say ‘check’. We don’t claim it’s definitely a version problem, but it might be, and the Ask site for the single suite lacks human-power available at place dealing with operating systems, but has an advantage of the different version test being much easier compared to OS upgrade.
Perhaps it should be mentioned that a current version of LibreOffice can also be downloaded here:
yes i get that. after you said it on the reply before it kinda seemed obvious right away. thanks again for the pov and overall help
also to clarify i am not judging the process suggested, i am just trying to permanently fix my issue here and most importantly understand what i did wrong in the first place because i think it’s more likely something i did caused it (see theory-crafting part in this reply above). also i truly don’t know if i could even check in a different computer. because it would require my set-up in order to reproduce conditions (LO but on latest version + zotero install + zotero plug in + loging in to sync my library + the fixed document) and i would need to work on it like 10 hours straight or something, because this bug appears sporadically and i cannot trigger it to check if it will happen in the latest version (i don’t know how to reproduce it exactly, hence the “it happens on it’s own” i wrote)
thanks for your input is a dual install of different versions of LO even possible or will it mix my preferences etc? anyway i wouldn’t mix my system with older and newer versions in the middle of a project just to be safe.
also worth mentioning for any future reader: debian has a backports version for a more recent version of LO (v. 24.8.2-1). however for my case this never seemed necessary to get the latest (since LO worked flawlessly with the stable version so far ) and mixing repos would mess up my system more that i am inclined to right now (especially since i got burned once in the past from mixing repos).
It is basically possible:
Alternatively, you could also upload your file to the cloud somewhere and post the link here or send it directly to a person in confidence, e.g. @mikekaganski .
You mentioned in a previous post you “imported” (pasted) bits from a DOC(X) documents and Word styles were added. This contradicts your statement about pasting as unformatted which would have inserted text only without formatting. Formatting in DOC(X) is based on different technical primitives with require conversion to be handled by Writer. This generally results in overlaid direct formatting for the primitives without basic equivalence.
“Importing” from alien sources without precaution is the beginning of document damage or “pollution” in the benign case. You should look on this side. If the “pollution” is rather light, it can be fixed and spurious styles removed. However if the “pollution density” is too high, the only cleaning solution is to paste unformatted in a blank document and restyle everything.
if so it’s a typo. i usually import unformatted, but this time i just copy pasted ‘as is’ to keep the subscript and superscripts intact and then i changed the style in the current document. sorry in case i made a typo and i am confusing things more (i redrafted my response several times in order to reply to everyone lol. this stated here is the correct anyway 
)
this is my suspicion. that’s why i said that the previous formatting (form the template i was using in a previous project) were still visible on the side bar even though i am technically not using them.
yeah, this i will avoid until finished. so far the bug haven’t reappeared at all since you asked me to test Ctrl+M and i opened a different file etc. i fear the issue must be the ‘Default Paragraph Style’ i use, because in between writing sessions i may open older projects or different ones (odt and doc) so if the default there is different than the default i use then it would impact one another as you said, correct? only thing i am not sure is if this is triggering the bug or not (i cannot reproduce it and frankly i don’t wish to try on purpose to bug it). All this combined with the large file, the mess from previous copy paste and the zotero direct formatting. 
update: the bug just happened again!
as i was writing my response above the power went out and my computer shut down. when i re-opened the computed the LO prompt asked me to recover the file. after seeing that unfortunately i lost about 0.5-1 hour of work, i noticed the open pilcrow again! so this time i close the file and open a previous version which was fine. then i reopen the current version and the pilcrow was normal again.
since i am experience power cuts this month, could it be related? i haven’t opened any other file on purpose, so i guess the ‘default paragraph style’ hypothesis is less strong now, or at least not as evident to me now.
so bug happened, fixed by closing and opening, the only thing change was the sudden shut down. as work as the temporary fix works it’s fine for now until i finish this project. any ideas on what may be causing it after this new info is welcome.
In Word, there is a feature of “paragraph mark formatting”, originally missing in Writer. That feature affects many Word-specific features, in very complicated ways; e.g., a paragraph mark may be made hidden, to effectively create a “merged” paragraph, consisting of two others, which themselves can have e.g. own numbering.
In 2019 (version 6.4), commit 5ba30f588d6e41a13d68b1461345fca7a7ca61ac implemented an initial, run-time support for that formatting - which meant, that we read it, stored internally, used where needed to correctly display the document, and wrote it back to DOCX - but we didn’t store it in ODT.
In 2022 (version 7.2), commit 6249858a8972aef077e0249bd93cfe8f01bce4d6 implemented saving of the marker formatting into ODT. That was done using a special empty text span at the end of the paragraph, which has own autostyle, representing the marker formatting.
(In 2023 (version 7.6), commit 1a88efa8e02a6d765dab13c7110443bb9e6acecf changed how it’s done - but that’s uninteresting for your 7.4.)
Why am I writing this? My suspicion is, that the feature may play some role in your case. There still is no UI to manage the stored paragraph mark formatting (even in the latest version) - meaning that you can’t add them anew (the only way to get them is from a DOCX), you can’t edit their property, and you can’t delete them using the program dialogs / controls, so the only way to get rid of it is to edit the XML.
If you feel like testing this, you may edit the ODT’s content.xml, to replace the following regex:
<text:span text:style-name="T\d+"/></text:p>
with
</text:p>
This removes those empty trailing spans from the paragraphs. I don’t know if it makes any difference for you, just a blind shot.
Indeed, making such changes must be done, only having a backup of your document.
thank you deeply for the detailed comprehensive response.
unfortunately i know little to nothing on this. thus i don’t know where it is/how to access this, and i don’t know if this is a system wise / LO installation file or a document specific file. meaning i am not sure i can tinker it safely mid-project without causing further issues (due to incompetence or miss-clicking (on my part)
if i understand correctly that means the copy-paste from the formatted docx i did month ago possibly “contaminated” my document with “paragraph mark formatting” from the source microsoft template, correct?
i am positive on trying this but i have some questions.
<text:span text:style-name="T\d+"/></text:p> ? or is this expected to be present in the xml either way so there is no point of first checking and reporting back here before moving on replacing?thanks again for your time
Yes.
That thread is not good for you. Using a Flat ODT would actually look like a nice option - but (1) FODT has its own set of bugs, so it is possible to loose something when converting to FODT; and (2) the resulting FODT from your 100MB-ODT would be really huge, so many tools would fail on it, or at least be painfully slow.
An ODT is in fact a ZIP file. Having your File1.odt, you may simply rename the file to File1.odt.zip, and then open it using any ZIP archive manager. That will allow you to see the content.xml right in the root of the archive. The idea is to extract it, edit it, and then replace the old version in the archive with the edited one. After your modifications, the updated File1.odt.zip should be renamed back to File1.odt, to be usable by Writer.
Why not check first? That would be a reasonable curiosity. The “free from paragraph marks formatting” documents are not expected to contain those. Open the XML using a plain text editor (like e.g. Notepad++), and search for that string, but make sure that you check “use regular expressions” (or similar wording) option in the search dialog.
The pair of <tag> ... </tag> is only required when there is the .... When the element is empty, i.e., there is neither content, nor sub-elements, in it, it may close itself right away - which is done using the trailing />, as in the discussed case, when the element (whole of it, auto-closing itself, and needing no separate closing pair - its presence would be a hard XML error in this case) should look like
<text:span text:style-name="T1"/>
immediately prior to the closing tag of the enclosing paragraph (text:p element).
it seems my file is not contaminated, am i reading this right?
step-by-step process i did: renamed with .zip → extracted the content.xml → opened with mousepad (a simple txt editor) → ctrl+F the expression <text:span text:style-name="T\d+"/></text:p> → the result was 0 occurrences (pictured above) 
PS: if you wish and the content.xml is not privacy sensitive i can link it/upload it here or in PM for you to check (file size 4.9 MB)?
No. You didn’t enable regular expressions.
content.xml contains most of the text in your document (not images, not headers/footers, but all the rest).
