Problem description: Creating a new document using the shell extension defaults to A4 page size. Steps to reproduce: 1. Navigate to any folder, including the desktop 2. Right click > New > OpenDocument Text (or Drawing) 3. Open newly created file 4. Navigate to Format > Page > Page tab [or] modify the Default page style Current behavior: Page format is A4. Expected behavior: Page format is Letter (based on what, though?). I don't see this issue when creating a new document using the LibreOffice desktop shortcut. It appears to me to be isolated to the shell extension. Platform (if different from the browser): Windows Vista 64 Browser: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0
@Rob, I think this is not a bug. The way you create a new document use the models on folder "Templates" of windows (and not models that you find in File - Templates). In this folder, you must have a soffice.odt (for writer), soffice.ods (for calc)... etc with the correct settings (Page letter in your case). You can copy a existing document template in this folder. Yves
I started to notice this problem (I think it's the same one) starting with 4.0 Right click in Explorer to create a new document, and open new document. It will be whatever LO has as it's original default document. Since I changed my default document template, I would expect that to be used for a new document. Under the older releases, when you opened this "blank" document, it would prompt to update styles from the default template, which would then work correctly (even though it seems like an extra step that shouldn't be needed). @ydutrieux - if you're saying that using the right click context menu and the menu within LibO itself used different template setups, then that sounds like a design issue, even if it's bug. How is a user going to know what template will be used in that case? And since there is currently now way to alter the template associated with a document, that is a problem.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
Still works the same as the original bug report. As Yves said, maybe this isn't a bug per se, but it's bad design. Once the document opens, it should at least prompt to update to the default template. Or whenever you set a new default template, LibO should update the templates stored in the place that Windows shell accesses.
according to previous comment I set status to NEW
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Still not working in 4.4.2 on Windows 8.1 64-bit. A document created via Explorer still defaults to the LibO original formatting for your locale. If does not assign or pickup and changes from any user selected default template.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
As the shell template is a predefined file, there is no way that i could think of that could make it locale dependent unless we shipped default templates for each locale, which doesnt seem reasonable to me. So i would close this as WONTFIX. Heiko, Stuart, Cor, Maxim: What's your take?
(In reply to Yousuf Philips (jay) from comment #9) > As the shell template is a predefined file, there is no way that i could > think of that could make it locale dependent... It would require code to decide between A4 and Letter (do we have more locale?). Or perhaps we could pack the two templates into the installer. Do we, @cloph? Sounds like an easyhack but no one was interested in fixing this issue in the last years. So WONTFIX is okay.
(In reply to Heiko Tietze from comment #10) > It would require code to decide between A4 and Letter (do we have more > locale?). The code to decide which page size is used by which locale is already existing, so in order for it to work with any locale, we'd have to modify the single shell template file in a way that uses that code. Else we'd have to create individual template files for each page size used by locales and make sure that template file is added to the windows shell during the installation, which i'm assuming isnt doable as the user doesnt pick their locale during installation. > Or perhaps we could pack the two templates into the installer. Do > we, @cloph? We'd have to bundle alot more than just two. > Sounds like an easyhack but no one was interested in fixing this issue in > the last years. So WONTFIX is okay. Closing it and if a dev says that its an easy fix, we can reopen.
Wouldn't the "correct" fix be to find some way to just link this to the user's default template rather than bundle a hard coded one in the installer? How many people alter something about the default template and would expect that to carry through to a "New > OpenDocument Text"? I know I do.
(In reply to Heiko Tietze from comment #10) > Sounds like an easyhack but no one was interested in fixing this issue in > the last years. So WONTFIX is okay. Is there a policy that non-easy-hack RFE's are closed ? Just asking.
(In reply to Cor Nouws from comment #13) > Is there a policy that non-easy-hack RFE's are closed ? Just asking. The policy is to balance effort and benefit. In c10 I wrote it might be simple but no one started to work on the patch followed by Jay's c11 easyhack argument.
(In reply to Heiko Tietze from comment #14) > (In reply to Cor Nouws from comment #13) > > Is there a policy that non-easy-hack RFE's are closed ? Just asking. > > The policy is to balance effort and benefit. In c10 I wrote it might be > simple but no one started to work on the patch followed by Jay's c11 > easyhack argument. So this issue is closed because it is not an easy hack and no comment from a developer showing interest or explaining that it is an easy hack.
(In reply to Cor Nouws from comment #15) > So this issue is closed because it is not an easy hack and no comment from a > developer showing interest or explaining that it is an easy hack. Whether EH or not, no interest over years is an argument to close the ticket. No problem if you want to reopen the ticket, but please have a second opinion to do so (not the OP of course).
FWIW the project has NEVER had a policy of "stale = close." It's a bad policy that has hurt projects in the past. Our community has always thrived on leaving valid requests/bugs open, even if in the end the bug will never be fixed or the enhancement will never be implemented.
(In reply to Joel Madero from comment #17) > FWIW the project has NEVER had a policy of "stale = close." It's a bad > policy that has hurt projects in the past. Our community has always thrived > on leaving valid requests/bugs open, even if in the end the bug will never > be fixed or the enhancement will never be implemented. Thanks Joel. I agree here > New
https://git.libreoffice.org/core/commit/3a7a06067e545670ef64367ef602469f507a3df7 and https://git.libreoffice.org/core/commit/ba0f4652b6743b3de6d692f87f688238a0eee9ce fixed this issue, because they added bare minimal OpenDocument Format files that do not have hardcoded page size.