This is a fairly old version.
Try a current version to see if the problem persists.
This is faulty. It is a “technical” used to define your preferred defaults (font face, size, indents, alignment, tab stops, …) shared by all other styles of your document. If you change something, it impacts all other styles. The intended style for your discourse in Body Text.
Zotero being multi-platform reimplements all formatting for its own use. As a consequence, Zotero formatting appears as direct formatting.
1 Like
thanks for the concern but this is the version on the current (stable) debian repository, i.e. this is the official version for my OS. also i am not going to do a major jump on updates (from 7 to 24) while i am working on a large project. finally, since i don’t have this issues with any other files, or at least i don’t recall it ever happening, i don’t see the version being relevant to the issue.
ok, Body text then. thanks
ok thanks for the info. although it won’t work (the plug in i mean) if i try and save on a different file type, i.e. docx
i guess it doesn’t affect the current issue. i write with the zotero plug in all the time and as far as i recall i don’t have this ever, it’s first time i see the formatting changing on it’s own without even being evident on the side bar. i will take notice and try to see if using the zotero plug in triggers it. if that’s it i will report back in here.
However, i have to say that since the formatting isn’t truly changing (based on the side bar info, like font, font size, text alignment, spacing, etc) then i have no clue why the normal pilcrow and the spacing of my text changes at all.
additions/edit:
i see how this could be the issue here. so me opening older versions and changing this may affect the new version since the default is shared. and if something is changing the default it may not be visible to me (on the info on the side bar) but only through the pilcrow symbol change and the overall document lengths/breaking of tables moving down etc. 
this is very interesting. i should change formatting to a document specific instead of ‘default’, however is I didn’t change formatting from older to newer versions, and as i am working on the manuscript the change happens “on its own” then i wonder if i shouldn’t change the formatting so to have the previous versions as a back-up plan 
(that’s it until i finish working on this project - the next should be done with a dedicated style from the start)
This is an interesting aspect.
Try the following:
Open your large file (no other files) and look in the status bar on the left at the page and page count display. Do nothing else and observe whether the number of pages changes.
I already had to deal with a similar case with a large file and many inserted areas that kept causing problems.
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.
1 Like
was hoping you would say yes so we can pinpoint the origin there or something
1 Like
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/
1 Like
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 ^^
1 Like
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.
1 Like
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:
Installing several versions of LibreOffice in parallel
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 .
1 Like
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.