Bug 48344 - Windows shell 'OpenDocument Text' template uses A4 page size rather than locale default
Summary: Windows shell 'OpenDocument Text' template uses A4 page size rather than loca...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: Desktop-Integration Templates Page
  Show dependency treegraph
 
Reported: 2012-04-05 09:29 UTC by Rob
Modified: 2017-06-21 16:08 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2012-04-05 09:29:50 UTC
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
Comment 1 ydutrieux 2012-12-14 18:16:45 UTC
@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
Comment 2 Jon Grossart 2013-04-02 19:26:10 UTC
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.
Comment 3 QA Administrators 2013-11-04 22:17:57 UTC Comment hidden (obsolete)
Comment 4 Jon Grossart 2013-11-05 18:10:14 UTC
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.
Comment 5 tommy27 2013-12-11 05:58:08 UTC
according to previous comment I set status to NEW
Comment 6 QA Administrators 2015-04-19 03:22:05 UTC Comment hidden (obsolete)
Comment 7 Jon Grossart 2015-04-19 17:54:26 UTC
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.
Comment 8 QA Administrators 2016-09-20 09:32:17 UTC Comment hidden (obsolete)
Comment 9 Yousuf Philips (jay) (retired) 2017-06-07 03:18:19 UTC
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?
Comment 10 Heiko Tietze 2017-06-07 07:16:21 UTC
(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.
Comment 11 Yousuf Philips (jay) (retired) 2017-06-07 21:47:01 UTC
(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.
Comment 12 Jon Grossart 2017-06-19 02:13:03 UTC
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.
Comment 13 Cor Nouws 2017-06-19 14:52:42 UTC
(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.
Comment 14 Heiko Tietze 2017-06-19 15:15:28 UTC
(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.
Comment 15 Cor Nouws 2017-06-19 18:23:56 UTC
(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.
Comment 16 Heiko Tietze 2017-06-19 20:10:15 UTC
(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).
Comment 17 Joel Madero 2017-06-20 04:58:49 UTC
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.
Comment 18 Cor Nouws 2017-06-20 19:58:44 UTC
(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