This was already a bug in OOo, but it wasn't every fixed. There is an extension for this, but it stopped being updated at LibO 3.3, and it has some issues. For example, it doesn't completely update the styles correctly. To me, this seems like something that should be core functionality, not an add-on (or at least a default add-on). OOo bug: https://issues.apache.org/ooo/show_bug.cgi?id=52783 Extension: http://extensions.libreoffice.org/extension-center/template-changer
As of LibreOffice 4.0.0.2, the template extension does not work at all. Given the changes made in the Template Manager, this extension needs to be rewritten.
This is crucial for me. I can't update to LO 4 until this functionality is present, wither via extension, or internally to LO.
So target would be to get the extension working again.
I supposed it would be fine to update the extension, but the problem was also that it didn't update the all the styles. However, this seems like such a basic thing that I don't even know why it's not a default feature instead of an extension.
Does https://bugs.freedesktop.org/show_bug.cgi?id=60660 duplicate this bug/feature request? See comment #3 in that #60660 comment thread for what is *needed*. Thank you!
I would say 60660 is a duplicate of this. RE: Comment 3: If the extension worked, that should be fine, however, something this basic should really be part of the core build since it is a VERY basic features, especially since they push using templates (and spent time redesigning the template manager).
*** Bug 60660 has been marked as a duplicate of this bug. ***
(In reply to comment #6) I think you're absolutely right. It should be a core feature of LibreOffice. But until it isn't the extension could do a great job and may be also bundled by default, so everyone get's this feature.
Note: A fix of Template Changer extension for LibreOffice 4: http://numbertext.org/tmp/template-changer-1.2.7b.oxt (Its menus have been moved to File » Send.)
I support this request and suggest it be added to MAB. While "File > Templates" with "Organize" was available up to LO 3.6, not in LO 4.0 and 4.1 now there's "File > Templates > Manage" in LO 4.2 but it's only for a new document, not for changing template in the existing document. I'd only like Template Changer menus to be available in "File > Templates" like up to template-changer-1.2.6.oxt and not in "File > Send" like in template-changer-1.2.7b.oxt.
Enhancement requests never belong on MAB list. Thanks for not adding it
Maybe here is an idea for the next GSoC ?
(In reply to comment #10) > [...] > I'd only like Template Changer menus to be available in "File > Templates" > like up to template-changer-1.2.6.oxt and not in "File > Send" like in > template-changer-1.2.7b.oxt. → https://bugs.freedesktop.org/show_bug.cgi?id=60592#c11 (Added bug 60592 to "See Also")
Created attachment 103193 [details] New version of Template Changer that resides under Files/Templates.
Since I use this functionality quite often, I thought that this extension was the only way to achieve it, but this functionality is in the core of LO. It resides in the dialog Styles and Formatting, icon top right, click-hold. Hope this info is of any use to visitors of this bug. I think this bug can be closed, since the extension is obsolete now.
@Patrick Smits I'm not sure that it does the same things as template changer By this way, I can load styles from a template, BUT the template file isn't linked to the document. You can see this by looking to the properties of your document (files/properties/General Tab --> template) So any update of your template file will not be propagated to your document. But this UI, can be used to add this feature. By just adding a check box "link this template to the document"
(In reply to Patrick Smits from comment #15) > Since I use this functionality quite often, I thought that this extension > was the only way to achieve it, but this functionality is in the core of LO. > It resides in the dialog Styles and Formatting, icon top right, click-hold. Can you please describe it little better or attach a screenshot? Do you mean "Load Styles..." icon? If so, that's not the same as template changer.
Timur & Pierre C: You're both right. Since the extension stopped working when upgrading to LO 4.4.0.3 I created a new bug (89286) to draw attention to this problem. In that bug Cor pointed me to a solution I didn't know about, and thought it would fix it for me, but you're both right: it doesn't.
Template Changer 1.2.7c (the one you attached here) seems to work for me on LO 4.4.0.3., installed in a clean profile on W7 64bit. I use Template Changer for documents on which I assign a template. Try one with different first page (logo) and you'll see that loading styles is sth. different. Bug 89286 looks like a duplicate to me.
Hi Timur, Thanks for your comment. I can install Template Changer 1.2.7c on two of my home machines, but it fails on my machine at work. So tomorrow at work I'll try again with a clean profile. Hope that helps. Nonetheless, as explained in my last comment on bug 89286, I strongly believe replacing templates should be stock functionality. It's been in MS Word since at least version '97. I regard this extension as merely a band aid, although I'm depending on it more than I want to admit ;-)
I understand that this bug IS about adding the ability of replacing templates as a stock functionality of LO. What might make confusion is that it's now marked as Component: Extensions. But in no way that should be about changing Template Changer extension, but about adding it to core LO. If that'll help, I suggest that be changed to Component: Framework or Component: Writer (because it works only with Writer). As written many times, Template Changer is one of the most frequent used extensions, and it's really justified to have it in core LO, or at least as bundled extension. Adding new bugs that ask for the same will unlikely help when those ones stay open for years. What might help is that you change bug 89286 to ask for Template Changer to become bundled with the installer (that's more important than Wiki Publisher I guess). What I'd like to know is where you got Template Changer 1.2.7c from, it's not updated neither in LO extensions nor in OO extensions.
> I understand that this bug IS about adding the ability of replacing > templates as a stock functionality of LO. > What might make confusion is that it's now marked as Component: Extensions. > But in no way that should be about changing Template Changer extension, but > about adding it to core LO. If that'll help, I suggest that be changed to > Component: Framework or Component: Writer (because it works only with > Writer). For me it sure would, because bug 60592 from Mirosław Zalewski about the Template Changer extension was marked as RESOLVED NOTOURBUG. Since comment #3 in this bug, there seemed to be a tendency in this thread to accept a fix for the extension as the solution to this bug. Combined with bug 60592 and the NOTOURBUG seemed like a dead end, hence my new bug report. So I support changing it. > As written many times, Template Changer is one of the most frequent used > extensions, and it's really justified to have it in core LO, or at least as > bundled extension. Adding new bugs that ask for the same will unlikely help > when those ones stay open for years. Agreed. > What might help is that you change bug 89286 to ask for Template Changer to > become bundled with the installer (that's more important than Wiki Publisher > I guess). Wouldn't that block a definite solution? > What I'd like to know is where you got Template Changer 1.2.7c from, it's > not updated neither in LO extensions nor in OO extensions. I download version 1.2.7b, renamed it to a .zip and examined its contents. This allowed me to slightly modify and fix it. P.S. At work it still doesn't install, I get an error that points to a permission problem: (com.sun.star.deployment.DeploymentException) { { Message = "You need write permissions to install this extension!", Context = (com.sun.star.uno.XInterface) @555c018 }, Cause = (any) { void } } The search continues, but now I really have to get some work done ;-)
So let's be clear here - we can't just bundle it "as is" - it's written most likely in Java. To make it into Core it'd have to be written in C++. If anyone on this thread wants to do so - please feel free to do it and submit it to gerrit.
@Joel Madero That's clear... And easy. This extension is not written in JAVA but OOBasic. This extension does not work since some OOBASIC functions were depreciated This extension is (were) one of the most popular on Both LO an LO Styles are a great OO/LO feature So, where is the problem telling that linking an existing doc to an existing template should be a core feature of LO ? The code is on the extension, less than 200 lines, and the code is highly commented. (that mean less than 100 real lines of code)
From my understanding it still has to be written in C++. If it's so clear and commented - feel free to create a C++ patch and submit it to gerrit.
@Joel Madero in other words : IF I don't know C++ I just have to shut up. Without this Knowledge, I'm not allowed to give my point view on this bug. Oh yes I can, but I won't be heard... OK So I'm wasting my time filling bugs. That wasn't clear for me. Now it is. thanks a lot
That clearly wasn't what I was saying at all. What I was saying is that when users who know no code say how easy things are to implement, they are likely mistaken. Just because an extension is well commented does not mean it's easy to implement (I would personally love to see CT2N brought into core...but it's not so easy). I have no issue with this ability being brought into core - all I'm saying is that: (1) it needs to be in c++; and (2) it's likely not as easy as one might assume if they aren't aware of c++ and the 10,000,000 lines of code that we already have. If you choose to take this as a personal insult, that's on you. I also am not a programmer (I dabble in C++ but this would be well above my abilities). And, I've been told on a number of occasions that things I assumed would be easy to do, would in fact be either impossible or really really hard. That's all I was saying...sorry if you read more into my comment than I intended
I did not take this as a personal insult but as an easy way to solve a problem or to answer a question. I don't know C++, but many other languages. Changing template link is just modifying XML. I'm sure it's not very difficult. It 's just the choice to not consider this as a priority. And I accept this choice. It just have to be assumed.
Last post on this (removing myself from cc) but need to say that we have no "collective priority" - we are a team of volunteers who individually choose what we want to implement. For more information (while not exactly on point, it gives a clear explanation of how there really is no "collective priority"): http://joelmadero.wordpress.com/2014/10/11/user-expectations-and-the-reality-of-our-community/?sn=c&c=326#comment-326
Since it's my bug, and it should be core functionality, and it was imported from the old tracker, I've updated it to LibreOffice. The reasons for that over writer, is that Impress also uses templates, and this functionality should exist there as well. So, Writer and Impress both need it. The extensions at best is a short term workaround in any fashion, as it should be core functionality as it ties in so explicitly with templates and styles.
I just entered into a few related items a) Normally if you create a document on template_1 by double clicking on it, the macro's stored in template_1 are available in the newly created document. However if you create macro's in a second template_2 and replace template_1 with template_2 with Template Changer, the macro's in template_2 are not available to the document. b) The same thing applies to keyboard shortcuts linked to macro's in templates. I guess this is because you cannot store keyboard shortcuts in templates. I am not sure if I should file them as bugs or feature requests though, since a) Template Changer is not an official part of the LO project. b) I'm not sure if this is by design or just a missing feature, since it may have security related consequences, p.e. you could link a malicious macro operation to a widely used keyboard shortcut. Any thoughts on that? P.S. not being able to install Template Changer at my work computer is solved. It was a permission issue.
I don't think it's reasonable to implement this. A template can contain any content, not only style definitions. What would you do with the content of a template when changing a document's template? A proper way to implement this is Document Themes. See bug 90497.
Samuel (comment #32), I disagree, but with proviso, refer: bug #101774 - I think this is the way to approach this bug #50699.
As in, once bug #101774 is implemented, then "template changer" will become much easier to implement: the template or master document can either directly define entities, or somehow link to an "entity template" (which is just a collection of named content). So I think this bug should stay open.
So I discovered we also have "Load Styles..." in Writer in the Styles menu. Using that, you can load Styles from another document into the current one. Is that an acceptable solution? Or is there something we can improve in that feature
If we load styles from a document or a template, the two documents are not linked. A change in the source document's (or template) styles will not be propagated to the other. When you create a document from a template. Each change to the template will be copied to the document when you (re)open it. The link can be seen to property doc tab (file/properties/tab General, line template) If this line is blank there is no link with a template) If a template is shown here this mean taht this doc is linked to this template. IMHO, here, the UI should allow to unlink the template, or link a(nother) template with a browse button
Hi Samual, I agree with Pierre C. A template is not just solely about text styles. When you create a document from a template, it contains all the styles and formatting as intended. In many organizations it may even contain text, headers, footers, logo's or any other common information that may not change for similar documents. Many organizations rely on templates for a uniform presentation and work flow.
Hi Patrick Smits Your comment reminds me what seems to be a bug OF LO 1) create a template, with a footer. 2) create a doc from this template 3) change the footer text in the template 4) reopen the doc (clic yes to update doc) => the footer is updated OK, all is right 5) add an image to the footer in the template 6) reopen the doc => the place for the image exists, but it's empty I think it's bug. Do you ?
Yes, the document should include or update the image.
@Pierre C has the right point of view. (AOo folks are not quite up to speed with Open Source's inroads into the enterprise world, they essentially blew this issue off). MS Word seems to meet this need, perhaps part of the reason (but only a small part, contracts and MS licensing protocols being the primary along with the continuing prejudice against Open Source) it is still prevalent in that space. @Patrick Many thanks for your efforts to fix the extension!
Created attachment 133738 [details] Template change dialog in MSO Word 2013 (German version) First tab is "Templates" where a text field let the user change the template of the document which is open just now. With a checkbox the user can define whether the styles of the template should be loaded automatically if they change.
Since "Template Changer" at LibO's extension website isn't working as intended (because 1) it doesn't link or change the template link that is visible in File > Properties... > General > Template, 2) you got an error and some styles are not updated and 3) the updated extension version 1.2.7d isn't available officially), it's no argument anymore that an extension instead of a built-in solution for the need described in this bug is the right way. (That is what I hear when talking about Template Changer with others in the community.) What a solution should be able to do: - Loading of styles that are part of a template file (can also be done with "Styles & Formatting" sidebar > Load styles...). - Loading of header/footer that are part of a template file (cf. https://bz.apache.org/ooo/show_bug.cgi?id=94360). - Loading of macros that are part of a template file. - Updating the <meta:template> tag in meta.xml. - Possibility to change the template via file menu and/or file properties dialog with a simple file explorer search window.
To summarize the discussion: It's requested to change the document appearance beyond just styles (c35) via template for Writer and Impress (c39). Additionally, some comments request also that changing the template later should affect the document (c36). There is an extension as workaround (c14). (In reply to Thomas Lendo from comment #42) > What a solution should be able to do: > - Loading of styles that are part of a template file (can also be done with > "Styles & Formatting" sidebar > Load styles...). > - Loading of header/footer that are part of a template file (cf. > https://bz.apache.org/ooo/show_bug.cgi?id=94360). > - Loading of macros that are part of a template file. > - Updating the <meta:template> tag in meta.xml. > - Possibility to change the template via file menu and/or file properties > dialog with a simple file explorer search window. Good start, and some questions: * Feature: Do we really want this workflow? Should document and template be linked so that changes to the template become effective later? * Scope: How about textboxes, containing the company address for instance? We can start with a basic set of course. * Workflow: How do we edit the template? We could ask the user whether a template should be opened and edited as it or applied to the current document. Alternatively an extra command "Apply template" could be better. The integration into the template manager is unclear. PS: I tagged all not utterly needed comments with no-value to improve the readability of this ticket; don't take this as any valuation.
*** Bug 89286 has been marked as a duplicate of this bug. ***
>* Feature: Do we really want this workflow? Should document and template be linked so that changes to the template become effective later? This is the current behaviour ! If you use a template, the new document created with this template is linked to it ? each modification of the template will be propagated to your document when you open it and you answer yes when UI ask you so. Anyone want to break this feature ? 16 user folows this bug. Template changer was one of the most used extension (now its broken since LO 4) It is also a feature request for AOO (https://bz.apache.org/ooo/show_bug.cgi?id=52783) with 18 votes. This feature exists in M$ office for ages Yes, I think it's a "must have" for advanced users
(In reply to Thomas Lendo from comment #42) > Since "Template Changer" at LibO's extension website isn't working as > intended (because 1) it doesn't link or change the template link that is > visible in File > Properties... > General > Template, 2) you got an error > and some styles are not updated and 3) the updated extension version 1.2.7d > isn't available officially) Hi Thomas, Version 1.2.7d is available at https://bugs.documentfoundation.org/show_bug.cgi?id=60592#c16. Today I tried to make 1.2.7c and d available at the Extensions repository, but I couldn't find a way to add it to https://extensions.libreoffice.org/extensions/template-changer.
(In reply to Heiko Tietze from comment #43) > * Feature: Do we really want this workflow? Should document and template be > linked so that changes to the template become effective later? I a new file is derived from a template (via the File > Templates > Manage Templates menu of File > New > Templates menu), the file is already linked to the template. This can be checked via File > Properties > General > Template. So nothing new here. > * Scope: How about textboxes, containing the company address for instance? > We can start with a basic set of course. Templates are all about standardization, not just styles, but also headers, footers, text boxes etc. To get a good impression about what should be included, please check https://templates.office.com > * Workflow: How do we edit the template? We could ask the user whether a > template should be opened and edited as it or applied to the current > document. Alternatively an extra command "Apply template" could be better. > The integration into the template manager is unclear. Templates can be edited via Manage Templates. Click right on a template and select Edit. If a template is edited and a linked file is opened LibreOffice already asks whether styles should be updated. See attachment.
Created attachment 139112 [details] LibreOffice already asks whether styles should be updated
(In reply to Heiko Tietze from comment #43) > * Feature: Do we really want this workflow? Should document and template be > linked so that changes to the template become effective later? As Pierre C said in comment 45 and Patrick Smits in comment 47, the current workflow with the extension is sufficient and need not to be changed. Please test the extension and you will see. For a developer, the extension can be the reference. > * Scope: How about textboxes, containing the company address for instance? > We can start with a basic set of course. As far as I know, textboxes and other objects are not in the scope of the extension. I wouldn't extend the scope of the feature by now. It worked very well till now. > * Workflow: How do we edit the template? We could ask the user whether a > template should be opened and edited as it or applied to the current > document. Alternatively an extra command "Apply template" could be better. > The integration into the template manager is unclear. As Patrick Smits said in comment 47, nothing has to be changed in the template manager or in the workflow with linked files. You can edit a template with the template manager. Editing the template always opens the current template available in the template manager. The only new that has to be implemented is the place where the link to a template can be applied or changed or deleted (as I said in the last point in my comment 42).
a template changes that does not have the ability/function to change the linked template is a bad idea.
(In reply to Cor Nouws from comment #50) > a template changes that does not have the ability/function to change the > linked template is a bad idea. a template changes => a template changer
Most of the functionality to implement this enhancement are already present. 1. if a template is updated, LibreOffice already asks if you want to update the styles when you open a document based on it 2. there is already code to manually load/update styles. What would be needed in the GUI to allow someone to change the associated template and the code to call the exist code to update the styles (which could probably even be a force close/reopen since that code path already does that in some way).
I haven't said much in the design meeting yesterday as all was said in this long bug report. I hope Stuart will read the comments and maybe test the extension so that we have another opinion. Misunderstandings ----------------- Second hope is that nobody closes this long-standing issue without knowing what the extension already did and does (I assume that because of the comments that were made) and what good help it is for current extension users. I explained the problems with the extension in comment 42. And additionally: The original author has no interest in the extension anymore. Naming/scope ------------ Third, I wouldn't attach importance to the wording "template". Template, style, document theme--nothing but smoke and mirrors. Precisely the extension is more a "styles changer" based on a specific template file. That's wanted as core feature in LO. (I don't know what the extension does, someone who can read the code should evaluate that.) MSO --- I tested MSO Word 2013 and only styles (paragraph, character, list and table) will be imported or updated. No page content, no page (style) definitions, no pictures, no frames, no objects, no fields, no header data, no footer data, no file properties (like title or company) will be changed or touched. UI -- What design team should discuss at a starting point is where should the template/style association can be edited in the GUI. (See last sentence in comment 49 or comment 52 or last point in comment 42.)
Thanks for your summary, Thomas, (In reply to Thomas Lendo from comment #53) > Misunderstandings > ----------------- > Second hope is that nobody closes this long-standing issue without knowing > what the extension already did and does (I assume that because of the ... In general the "I don't get this issue and don't need it, so close the issue"-rate is very low here :) > additionally: The original author has no interest in the extension anymore. ... For me it is marked as (possibly) todo. > MSO > --- > I tested MSO Word 2013 and only styles (paragraph, character, list and > table) will be imported or updated. No page content, no page (style) ... Which is logic. MsOffice doesn't have page styles (poor users), and those and content of the page styles (such as images in headers) is therefore not imported. > UI > -- > What design team should discuss at a starting point is where should the > template/style association can be edited in the GUI. (See last sentence in > comment 49 or comment 52 or last point in comment 42.) Good idea. IMO.
Hi guys, This is an important feature for me. IIUC, there seems to be some controversy over what changing the underlying document template should do. The current LO scheme, of asking to update Styles only, is to my mind the correct one. Content built into a template is never written over an existing document, only styles are. So then, what's the need of changing the underlying template? So that a document's styles can stay synced with a template of choice. The current problem comes when a document is radically changed. For instance, I recently took a long document and changed it from a normal 8.5x11 page to a 2-up 5.5x8.5 mirrored book format, and chose an inverted color scheme for readability. Virtually all the styles were affected, and now I dare not sync that document to its original template, which it is stuck with. I want to assign a "graybook" template to it, but cannot. Any improvements I make to my graybook template cannot be carried over to any document not bearing its formal lineage. The alternative, I guess, would be to copy/paste all document contents to a blank "graybook" document and resave, but I'm not sure all content, such as foot/endnotes, would make the transition. Something that radical, IMO, should not be necessary. So the issue of changing templates, in my mind, is about Styles, and nothing more. Themes is a related but subtly different concept, whereby a document's text styles can be quickly changed, with visual feedback on the fly, without affecting page settings. We can approximate this by use of different templates, but Themes makes the function much more accessible, IME. My vote would be that this is core functionality. It could be done in several ways, but I think the most intuitive would be at the Manage Templates dialog, where an "Apply Template to Current Document" command could be added. BW
Paul's comment 55 sounds like the best compromise here. Everything that is a style is taken from the template and gets updated when the template changes. All other features such as fields, shapes, or images are ignored. Sounds very much like the experimental document theme and why should both do the same?
(In reply to Heiko Tietze from comment #56) > Paul's comment 55 sounds like the best compromise here. Everything that is a > style is taken from the template and gets updated when the template changes. Indeed. So the associated template is changed. > All other features such as fields, shapes, or images are ignored. Correct. > Sounds very much like the experimental document theme and why should both > do the same? I think that once the Theme X from the available themes is applied to File Y, changes to the available Theme X won't have any effect on File Y.
(In reply to Heiko Tietze from comment #56) > Sounds > very much like the experimental document theme and why should both do the > same? I wouldn't mix template association with document theming (bug 90497 - Implementing document themes). You can choose a document theme for your document and save it as a template, then you can change the template of an existing document to this new template. Seems as completely different use cases.
Some are following this line to fix the issue. That's great. I would like to add some info from my own time I spent finding a solution, if not provided so far in the existing comments since I did not check them all. Also my opinion on the design part of it. There is the concept of sticky templates which after creating many documents with LO just encountered recently: https://help.libreoffice.org/Common/Open_1#Opening_Documents_With_Templates That could easily take a person's time by updating and seeing no results. Better call it sticky trick. Also this wiki on template management seems out of date: https://help.libreoffice.org/Common/Template_Management
Different strains seem to get mixed up in this discussion which should be clearly separated (details follow below). I list them because they have been alluded to somewhere, in order to get rid of most of them quickly: 1. The possibility to change a document template attached to a document, the initial reason for this bug report (for which I question the need in many cases) 2. The ability to update the styles used in a document using a model - which can be any document or a template in the way LibO uses this term 3. The use of a template to initialize some aspects of newly created documents 4. The ability to promote changes of this template to the documents attached to it Comment #30 talks of Writer and Impress, but this is relevant for Calc and Draw as well. Comments #32, 37 and 47 correctly state that not only styles are involved (in contrast to Comment #52 which seems to imply the contrary). It might be useful to first recall what LibO already can do. My tests have been primarily been done with Calc, because my interest was triggered by someone asking about Calc Templates, but this may be even an advantage, as most people on this thread seem to be looking to Writer and perhaps Impress. - There is the possibility to copy (and eventually overwrite) all styles of a document using another document (which must not be a so-called template) as a starting-point, in Writer. This would indeed be wished for for Calc, Draw and Impress too. So #2 is available for writer , but desired for the other modules. - There is the possibilty to create document templates (in each of the LibO modules) which may be used to set many of the quite complex attributes of a new document by copying. No one in this thread seems to question the extent of the copied attributes, so we take this function as accepted. This covers #3. - Promoting changes (#4) in a template created according to #3 is done by LibO: you will be asked if you want to accept changing all relevant settings using the template or not. This includes not only character and paragraph styles, but also footer and header settings, including attributes for the texts of the divers components of these and e.g.borders of these. Unfortunately, the text of the prompt uses the wording "update Styles", but in fact there will be done more: most (or all, I'm, not sure) settings will be changed. So, excepting the extension of #2 to all components, question #1 remains to be discussed. Now, looking at this question more closely: You may well design a series of cascading templates using ever more concrete settings, and changing one of these at a parent level would probably (as I hope) trigger questions about propagating these changes at the lower level (by already existing LibO functionality). This might be a scenario for a bigger company using lots of document templates which are base on simpler models, which again use other models etc. But I don't see a frequent need to set a different template to the document: the changes should be done by changing the settings of the parent document (which could be some steps higher in the lineage). Thus I think that really replacing a document template by another is a very extreme and seldom occasion. It could be done, as far as I know, by the following macro, which should be located, as far as the momentary coding is used, within the document: Sub setzeVorlageInfos dim dt as NEW com.sun.star.util.DateTime oDoc = ThisComponent prop = oDoc.DocumentProperties prop.TemplateName = "master2" 'set Name, this example fits the file name in the following statement prop.TemplateURL = ConvertToURL("C:\Users\gerha\AppData\Roaming\LibreOffice\4\user\template\master2.ots") 'this is an example dt = prop.TemplateDate 'Date ist set to 'zero', so there will be a prompt because of differnent time stamp dt.Nanoseconds = 0 dt.Seconds = 0 dt.Minutes = 0 dt.Hours = 0 dt.Day = 0 dt.Month = 0 dt.Year = 0 dt.IsUTC = FALSE ' bis hier... prop.TemplateDate = dt End Sub After using this macro, the document should be opened, because then the user would be prompted to apply the changes caused by the new template to the document. Thus, all necessary changes will be done. Thus, this simple macro in combination with the existing functionality of LibO seems to me to be doing all that is necessary. I still want to repeat that I think that there is rarely a need to change the template of a document (whereas I quite see the need for changing the existing template, a scenario which seems to be coverd by Libo standards). But for these rare cases I think using a macro is sufficient, adding functionality to LibO core I deem not necessary. My summary is that there is no need for a core functionality to change the link to a document template, as this seems to be a rare exigency. The normal case would be to change the existing template; and for these extrem cases a macro is provided. ÜPerhaps I'm wrong in judging the need for changing the template. But then please provide convincing examples.
After two or three days since I posted my comment I think it might sound a bit harsh. In fact I am thinking about providing a new solution for this problem, which will certainly not be completely differing from Template Changer. This extension has, as far as I now see, some shortcomings, e.g. the restriction to Writer, the cause of which I do not understand at the moment, my first tests were done in Calc and did work, and - as it seems - the assumption of always changing all files of a directory with certain extensions - , but the problem, that it no longer works, is obviously only due to the renaming of some LibO variables, I made it work in a test case by changing them. I still think that there is not so much need for the functionality, so I'm not sure yet whether I will supply an extension with a menu entry in LibO or a simple document that includes a macro to be started from there (which nevertheless could probably be easily copied to MyMacros, although). In any case I will only set all relevant information concerning the new template, leaving the changing of the formatting to LibO which will prompt for it when the document is opened for the next time (there's some meddling with numbering styles in Template Changer which I do not understand); I think that is the only feasible way to add a function in this quite complex situation, leaving to LibO to do the work. I'll post a message here when the "extension" is published.
@Gerhard Weydt I need to link a template to a document. Mostly to re-link. Because link can be loosed by too ways (at least) : - If you choose "don't update styles" when template has changed - If you open and work with your document and the template is not where it should be (works on another computer, network link failed, worng configuration of templates path...)
(In reply to Pierre C from comment #62) > @Gerhard Weydt > I need to link a template to a document. Mostly to re-link. Because link can > be loosed by too ways (at least) : > - If you choose "don't update styles" when template has changed > - If you open and work with your document and the template is not where it > should be (works on another computer, network link failed, worng > configuration of templates path...) Ok, these are convincing reasons for the need of this functionality which I asked for in comment 60. As I didn't use document templates yet, I had no experience with those situations. I will continue to work an a solution, which in my case can only be an extension. I already could make the old template changer extension work again in my installation by changing some variable names which obviously have been changed in some version of LibO. But I also want to expand the scope to the other document types in LibO, because I don't think the restriction to Writer is crucial, and to add the feature to not only cut the coupling to a template, but even erase the information that it once was linked, which is still being kept when one has denied the question to transfer the changed formatting to the document. The question for that posed by a user was the reason I started to look into this subject. I don't know yet whether I will be able to change the old extension or to create a new one.
The main reasons to relink a document to the a different template (besides the ones where it doesn't link to a new change -- and I've definitely had template links get broken even with the template still exists) if you occasionally change your default template and want old documents to be easily updated to the new format. Currently, that involves: 1. load the styles from another document 2. create a document from the new template 3. copy and paste over so that the correct styles are supplied If you just copy and paste the text over, you either keep the old text (because it keeps the extra formatting on top of the style version) or you past unformatted, but then you need to go back and fix everything. For me, I run a small business, and there are times when I want to keep a document linked to header from a specific time, but then easily copy the document over and update to the new header as well. Think for things like generating reports and such. I need to keep both header templates around, not just change the base one. As mentioned, writer and Impress probably need this the most, but other apps can benefit from it as well. And seeing as how the basic functionality is already in LibO (since it can update styles) and it would help give parity to Word/MS Office (which can use Quick Styles which is essentially super fast template switching with preview -- but there is an enhancement request for that), I don't see why there so much against this request.
I now filed a new extension named "DocumentTemplateChanger", which at the moment still waits for revision before it will be published. It works for Writer, Calc, Impress and Draw and has additional features, compared to TemplateChanger. Most important is perhaps the ability to connect again to the template if one has inadvertently answered by No when asked whether the styles sould be updated. I hope this helps as long as there is no solution in standard LibreOffice.
(In reply to Gerhard Weydt from comment #65) > I now filed a new extension named "DocumentTemplateChanger", which at the > moment still waits for revision before it will be published. > It works for Writer, Calc, Impress and Draw and has additional features, > compared to TemplateChanger. Most important is perhaps the ability to > connect again to the template if one has inadvertently answered by No when > asked whether the styles sould be updated. > I hope this helps as long as there is no solution in standard LibreOffice. Great ! Where can I download and test this extension ?
Created attachment 149243 [details] New extension Document Template Changer as a substitute It has been a week that the extension was published by me, with the message that it had still to be revised. Nothing has happened since. I'll stick to the case, but meanwhile I publish the file here.
(In reply to Gerhard Weydt from comment #67) > Created attachment 149243 [details] > New extension Document Template Changer as a substitute > > It has been a week that the extension was published by me, with the message > that it had still to be revised. Nothing has happened since. I'll stick to > the case, but meanwhile I publish the file here. The extension is now available in https://extensions.libreoffice.org/extensions/documenttemplatechanger
Created attachment 151533 [details] Error in extension
I've an error with the extension, when linking a template to a doc. (see attached)
(In reply to Pierre C from comment #70) > I've an error with the extension, when linking a template to a doc. (see > attached) Hi Pierre, I could not contact you by direct mail in order to get a test file due to - probably - technical problems of the mail provider(s), hence I do not know which special constellation caused the error (I vainly tried to create a file which produced an error). So I added a test to the code which simply avoids evaluating the attribute which caused the error, if it's not present, which does no harm, as the statements executed apply only to this attribute. This is contained in the new version 1.0.2 on the extensions website. Please test your file with this new version.
(In reply to Gerhard Weydt from comment #71) > > Hi Pierre, > > I could not contact you by direct mail in order to get a test file due to - > probably - technical problems of the mail provider(s), hence I do not know > which special constellation caused the error (I vainly tried to create a > file which produced an error). > So I added a test to the code which simply avoids evaluating the attribute > which caused the error, if it's not present, which does no harm, as the > statements executed apply only to this attribute. > This is contained in the new version 1.0.2 on the extensions website. Please > test your file with this new version. Hi, You can contact me to : - The name just after Hi - dot - choffardet - at free.fr
A really long discussion. I started to read, but then stopped. It should be considered that: 1. Writer has built-in an option to load the styles: Main menu > "Styles" > "Load Styles" or "Styles" pane > "New Style from Selection" button > Load Styles 2. Using the previous way, the template will not be "sticky", i.e. the styles in the document will not be automatically updated according to the changes in the template. But there is nothing critical, we have another way: 1. Copy your custom template in the Templates folder. 2. Create new document based on this document using main menu > "File" > "New" > "Templates". Save it. (The location of the "Templates" folder could be discovered using main menu > Tools > Options > LibreOffice > Paths > Templates). 3. Done. The template is now associated with your document. Then, if you want to de-associate them, repeat the above-mentioned steps, but now the template should be outside of the Templates folder. Please, correct me in case it's not true - because I'm just a random guy here.
A link to my previous message: https://help.libreoffice.org/Common/Open_1#Opening_Documents_With_Templates And its duplicate: https://ask.libreoffice.org/en/question/94134/synchronize-style-sheets-across-documents/
(In reply to John from comment #73) > A really long discussion. I started to read, but then stopped. > > It should be considered that: > > 1. > > Writer has built-in an option to load the styles: > > Main menu > "Styles" > "Load Styles" > or > "Styles" pane > "New Style from Selection" button > Load Styles > > 2. > > Using the previous way, the template will not be "sticky", i.e. the styles > in the document will not be automatically updated according to the changes > in the template. > > But there is nothing critical, we have another way: > > 1. Copy your custom template in the Templates folder. > 2. Create new document based on this document using main menu > "File" > > "New" > "Templates". Save it. (The location of the "Templates" folder could > be discovered using main menu > Tools > Options > LibreOffice > Paths > > Templates). > 3. Done. The template is now associated with your document. Then, if you > want to de-associate them, repeat the above-mentioned steps, but now the > template should be outside of the Templates folder. > > Please, correct me in case it's not true - because I'm just a random guy > here. First: A general remark: You should never comment on a text you haven't read through! Second: What you describe in point 2 is the way to base a new document on a template. But this is not the object of the present discussion. It is concerned with associating another template to an already existing document. Third: If you really mean what you say in point 3, then this is an impossibility: One should create a new document on a template that is not available via "File" > "New" > "Templates" by using this menu path!
(In reply to Gerhard Weydt from comment #75) > Second I mean that it could be used as a workaround: instead of trying to change the template of the existing document: 1. create a new document associated with the required template 2. replace the contents of the new document with the contents of the old document (Select All > Cut > Paste). I'm not going to say that this workaround is really good. * First of all, it's not very quick and intuitive. * Also, the meta-information will be lost (File > Properties > Description). These two pitfalls weren't visible for me when I posted my previous message. And therefore I was sure that the described workaround is much better. Now I changed my mind. > Third Yes, you are correct. I mean that in this case the template should be launched using general-purpose file manager.
(In reply to John from comment #76) > (In reply to Gerhard Weydt from comment #75) > > > Second > > I mean that it could be used as a workaround: instead of trying to change > the template of the existing document: > > 1. create a new document associated with the required template > 2. replace the contents of the new document with the contents of the old > document (Select All > Cut > Paste). > > I'm not going to say that this workaround is really good. > > * First of all, it's not very quick and intuitive. > * Also, the meta-information will be lost (File > Properties > Description). > > These two pitfalls weren't visible for me when I posted my previous message. > And therefore I was sure that the described workaround is much better. Now I > changed my mind. > > > Third > > Yes, you are correct. I mean that in this case the template should be > launched using general-purpose file manager. To deal with your last two lines quickly: I still don't understand that, because the aim is to use no template or to cut the link to a used template, so why should there be the need to "launch" (whatever that means) a template? But the main point is, and perhaps you missed it because you stopped reading somewhere, as you confessed: There is an extension doing all that is asked for, see comment 68. The workaround to create a new document based on the new template and then cpoying the content of the previous document does work, but it requires some work. I first thought that no great problem, when I stumbled over the bug report, but people reported problems with broken links (see comments 62 and following), so I realized that this could be a lot of work if many documents were afffected. There was an older extension which did not work any longer, due to some technical reason, and the author could not be reached. So I decided to create a new extension, after I had been convinced that there was a need for it. I don't know for the moment how much I relied on his code. The extension allows to link another template to an existing document (changing the appearance whereever changed styles are concerned), to cut the link to the template (i. e. disregard present and future changes to the template, which is , as I assume now without additional testing, the same as renouncing to update a document with respect to the template when opening it), to reactivate this link (there is no function for that in standard LibO), and to deelete the link, leaving the document as permanently stand-alone without template (again there's no LibO function. So I think there is no need for thinking about workarounds. The extension seems to work, as 14 persons voted it up and no one voted it down; a big number of votes should not be expected for such a special feature.
Changing priority back to 'medium' since the number of duplicates is lower than 5
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
what's the status on this extension for LO 6.4.4? is it available? maintained? comment #68 links to a Page not found page, and a search on https://extensions.libreoffice.org/?q=template+changer only lists the old one.
(In reply to jeroen van gorkum from comment #80) > what's the status on this extension for LO 6.4.4? is it available? > maintained? > > comment #68 links to a Page not found page, and a search on > https://extensions.libreoffice.org/?q=template+changer only lists the old > one. It's a long discussion, and perhaps you have not read through all comments, but I have provided an extension which replaces the old extension which no longer works because of some changes in LibO which have not been reflected in the old extension. It seems that the author is no longer to be found or not replying. You can find the link to the new extension "DocumentTemplateChanger" in comment #68. Unfortunately it seems not possible to add a link to the new extension in the old one, because one has to be the author of that to add text.
(In reply to Gerhard Weydt from comment #81) > It's a long discussion, and perhaps you have not read through all comments, i've read this thread (and others about template changer) in their entirety, because i need this functionality to switch successfully from AOO to LO. > It seems that the author is no longer to be found or not replying. [...] > Unfortunately it seems not possible to add a link to the new extension in > the old one, because one has to be the author of that to add text. of course it's not up to me, but André (author) said in bug 60592, comment 6 that his work is LGPL. so why not release a new version of Template Changer on the Extensions website that is under your control?
Off-topic: Anyone can take over the maintainership of an extension now. Just ask the infra team, release manager, or me.
(In reply to Gerhard Weydt from comment #68) > (In reply to Gerhard Weydt from comment #67) > > Created attachment 149243 [details] > > New extension Document Template Changer as a substitute > > > > It has been a week that the extension was published by me, with the message > > that it had still to be revised. Nothing has happened since. I'll stick to > > the case, but meanwhile I publish the file here. > > The extension is now available in > https://extensions.libreoffice.org/extensions/documenttemplatechanger Thank you for this! It works on single documents, but not on folders. I use custom paths so that my templates get backed up automatically...maybe that is the problem? As it stands, in the dialog to change directories, there is nothing in any of the dropdowns, and opening the file chooser (...)doesn't invoke the file manager. I have LO 6.3 via manjaro still. I set LO to use the system file chooser as I don't like the LO one, so maybe that is the case? I am not the only one, another commentator left a review on the LO templates site having the same problem. THanks for this extension!
Since the extension site has been changed, the extension is available via https://extensions.libreoffice.org/en/extensions/show/template-changer
This is a bug but it needs to be fixed. Template associated with document must accommodate changing. I have recently used an online contract termination template that was easy to fill in and modify. Visit https://www.kuendigung.services/vorlage/kuendigung/telekom. They are well known contract termination service provider. They use quality template to save our time.
(In reply to Gerhard Weydt from comment #85) > Since the extension site has been changed, the extension is available via > https://extensions.libreoffice.org/en/extensions/show/template-changer Thanks, Gerhard. Just in case, for a better understanding: 1. There was an abandoned extension Template Changer by another author. 2. Because the original extension was abandoned, Gerhard created a new one, DocumentTemplateChanger, and it was available via https://extensions.libreoffice.org/extensions/documenttemplatechanger 3. Now Gerhard's extension changed its name back to Template Changer and it is available under the original url. I hope I haven't messed anything.
(In reply to emmapk1 from comment #86) > This is a bug but it needs to be fixed. Template associated with document > must accommodate changing. I have recently used an online contract > termination template that was easy to fill in and modify. Visit > https://www.kuendigung.services/vorlage/kuendigung/telekom. They are well > known contract termination service provider. They use quality template to > save our time. I agree that it would be better to have this functionality within LibO and not only in an extension. But the example that you provide has nothing to do with a LibO template, it's a totally different type, what is often called a form. As you seem to be German or living in Germany: a form is "Formular", template is "Vorlage".
(In reply to John from comment #87) > (In reply to Gerhard Weydt from comment #85) > > Since the extension site has been changed, the extension is available via > > https://extensions.libreoffice.org/en/extensions/show/template-changer > > Thanks, Gerhard. > > Just in case, for a better understanding: > > 1. There was an abandoned extension Template Changer by another author. > > 2. Because the original extension was abandoned, Gerhard created a new one, > DocumentTemplateChanger, and it was available via > https://extensions.libreoffice.org/extensions/documenttemplatechanger > > 3. Now Gerhard's extension changed its name back to Template Changer and it > is available under the original url. > > I hope I haven't messed anything. That's correct. I just want to add, that the version 2.0.0 (at the original URL) was not entirely correct, of which I wasn't aware, because for a longer time I could not access the extension. A corrected version 2.0.1 is now available there.