Attach your “bound” document and the template so that I can have a look.
My .odt file is problematic for forum software, this message editor. Attaching it to message never completes “Processing uploades…”. Doesn’t matter if this threat, or PM.
No problems to attach .ott. No idea on my side what’s wrong.
My .odt file unfortunately doen’t upload here. Upload process never completes. It failed several hours ago yet it fails right now. I don’t know what may be the reason. Size of file is about 13kB.
If to abstract from DF be breaking the link template to document what are other possible reasons for that connection to not work?
Removing DF never breaks links. There is probably something in your configuration. See my proposal in your AskLO private mail.
In my mind is if DF is present it is the first suspect for broken link template-document as it was here.
@mikekaganski
Could you have a look at these two files or hand them over to an available developer?
tmplt01.ott (10.1 KB)
writeup-A.odt (10.1 KB)
After a change to the template, the style update dialog does not show up. However, if I play my favourite trick:
- save the .odt as .fodt
- open the .fodt with a text editor and change template time stamp in metadata (here I went one month back); save
- open the patched .fodt with LO
then the style update dialog shows up.
I tried to check metadata in the .ott and it looks like its timestamp is not changed (but not 100% sure about it). Could there be some circumstances where this timestamp is not updated?
By “timestamp” I mean what is recorded in metadata, not OS last changed date.
I had this kind of problem a couple of years ago and solved it with the trick above (not very friendly). However the issue didn’t occur again after some time.
My LO release is 7.6.4.1 (quite up-to-date). I don’t think OS is relevant. I am Fedora 39 and OP Win 10 or 11.
One of former discussions provides me with further hint - template relative path stored to .odt must land to template real path. This can be the reason in my case here - mismatching template path in my .odt.
No. To avoid this kind of problem, I used TemplateChanger to make sure template link pointed on the correct file. I even experimented with a manually changed path in metadata to discard any relative path misinterpretation. I could get the style update dialog only after I changed the timestamp reference for the template in the .odt.
To check my thesis I flattened .odt to .fodt then looked for template path in .odt and copied it to clipboard.
<meta:template xlink:type=“simple” meta:date=“2024-02-08T21:03:49.934572131” xlink:href="…/…/…/…/…/…/…/…/…/…/home/userA/Templates/bla/bla/bla/bla/blaaa.ott" xlink:actuate=“onRequest” xlink:title=“PrjA”/>
Then in shell changed working directory to my .odt storage directory and did ls -alh <path from .fodt> which returns with error.
Path found in .fodt starts with quite long sequence of ../'s - in end result path switches to parent directory 10 times before specifying remaining path part literally (which starts with /home).
If to do ls -alh ../../../../../../../../../.. it doesn’t land to the spot in file tree where I expect it to land. Instead of that it lands in /home which is bad because the string in path of literal path specification starts either with /home.
It can be my shifting of template file in past.
I guess TemplateExchange to fix it. Right?
More exactly TemplateChanger. I used it because I feared your directory structure would be different from mine. But I still suffer from the problem until I trick LO on last template changed date.
I saw that your template was initially created in 2015. Perhaps something happened during its edit history. Unfortunately, 2015 is “eternity” in computer science and it is impossible to remember everything you did on the template.
Template path in .odt fixed using TemplateChanger. Now path found in flattened document works fine in shell. However document still doesn’t prompt on its opening if template got modification - as ajlittoz reports its too.
Template history - myself was looking for file Default in user home.
Reason my template shouldn’t start from scratch but from the one provided by Writer installer.
Found one Default.ott in libreoffice sub-directory, then duplicated it, renamed the duplicate according to own needs, finally registered with Write (custom Category, custom Templates path). All these steps were conducted at beginning of current write-up works - recent 3 weeks. Afterward custom styles get added, documents get derived.
EDIT
LibreOffice Options >Paths > variable Templates : three paths are listed, one spawn by LibreOffice (default) + one custom for current write-up + one custom for experiments
Does one need to do it just once?
Can I use it to fix for me? If yes, how (.fodt back to .odt)?
This is a hack. I don’t recommend to do it routinely. It is acceptable for testing but there are so many chances to damage the file that it is preferable to wait for developers’ analysis. As I said, it occurred to me in the past. I used the trick during an interim period and everything was back to normal after some updates (both to my template, the dependent document and LO). As everything worked then smoothly, I didn’t explore thoroughly which circumstances caused the problem nor those which fixed it.
Apparently (once again, I am no developer), the timestamp is not updated when some changes (which? why?) are made on the template. This is a bug, but a report can be submitted only once we get an idea on the track to follow, i.e. cause the bug deterministically.
Thank you for information.
Will it be possible to continue proceeding according following plan:
- use master, a set of sub-documents and one single template for all of them
- let the set of custom styles to maturate in course of write work progress
Writing starts right now.
Sounds like at certain points the manual maintenance and distribution of custom styles among whole writing to be necessary.
“Optimising” document formatting is an iterative process. Unless you are exceptionally smart (when it comes to aesthetics issues, I am certainly not), you never design your “ideal” styles from the start. The most important point is to define the set of semantic styles you need. I write semantic because you must consider styling as a “significance annotation” of your text. As an author, you, and only you, know which paragraphs or words are headings, main topic, comments, notes, important, humour, irony, … The name you give to the corresponding styles won’t change during the course of writing. Don’t bother yourself with the appearance at this stage. As long as the styles (their names) allow to make a distinction between the “values” in the document (the abstract significance categories), you can defer the formatting tuning step. Just ensure the present state of the styles give you a sufficient visual feedback.
When it is time to tune formatting, play only with the styles. If there is no direct formatting, there is nothing else to do. This is why it is important to reduce direct formatting to the absolute minimum. Otherwise it is a real nightmare. You’ll soon discover that, contrary to common belief, use styles is much simpler, efficient and effective than direct formatting.
One last word: don’t go for master+subdocuments unless there is a real need for it. Present-day computers are powerful enough to handle 800-1000 pages single-file documents (without images or tables), even laptops. The limit may be smaller if your document structure is complex.
The master feature is a good solution when the sub-documents are shared and reused without modification in several “works” (books). But if the document is unique, there is no real reason to make things more difficult unless you’re on several thousands page book. The master feature introduces subtleties with new difficulties. Consequently, think twice before deciding.
Thanks for this feedback.
It is not the tooling I use for my current writing where doubts arise sufficient capacities to be present. It is rather me why I am convinced to use master document. In the end this writing will have thirty up to forty pages. I hate namely get serviced huge cow on my desk every time my job is to process just the stack.
I believe to achieve higher productivity on using master. The more progress the writing will do the harder will it be to handle it in one piece. I am not a friend of dealing with huge objects. If handling of huge object is necessary than only at appropriate level of its internals (the highest level only).
In writing a document the final phase is critical, it is the phase when digging into chapters may be necessary for corrections. Every time I will need to work on one single chapter I don’t want to have the whole on my desk.
I do not plan to have that level of expression forms variety in my writing. For sure I will have headings of document structure elements, text body, couple of caption styles, one bullet list style. Small set of character styles, page styles, list styles to complete the collection. Few further may arise in course of writing however I don’t expect the number of expression forms to be high. Rather, the following will apply - comments, notes, important, humor, irony, as expressing forms won’t be used.
@ajlittoz
As of time being two major points in my current work:
-
I am still not convinced to drop the plan of master document use. For planned file size of document it won’t be comfortable for me to work with the whole in one piece. Sure, problem doesn’t exist from starting of my writing on. Threshold gets reached in course of writing. But master document helps to higher structuring in work, additional boost for productivity.
-
Template update propagation to derived document doesn’t work at this moment. It’s unclear how soon it will work again.
In this situation no idea about best approach to use workaround yet be prepared to go back to functional template-document update channel.
As for current situation it’s unclear how can I maintain styles in template and sub-documents. Master is not at that level of urgency as I plan to spawn master at later point of time.
As an input from my side: I can confirm in case of template here (current writing) the author unchecked Apply user data. Child documents inherit this setting.