Bug Hunting Session
Bug 86336 - FILEOPEN Calc ignores custom template when opening csv file
Summary: FILEOPEN Calc ignores custom template when opening csv file
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: low minor
Assignee: Not Assigned
Depends on:
Blocks: CSV-Import
  Show dependency treegraph
Reported: 2014-11-16 10:51 UTC by FS
Modified: 2019-07-22 02:44 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Example CSV file for testing (62 bytes, text/csv)
2014-11-17 12:31 UTC, FS

Note You need to log in before you can comment on or make changes to this bug.
Description FS 2014-11-16 10:51:41 UTC
Current behaviour: Calc ignores a custom template set as default when opening a CSV file.

Expected behaviour: When opening a CSV file and with a custom template set as default, Calc uses that custom template to display the csv file.

Steps to reproduce:

1. Create a custom calc template:
a. Create a new Calc file;
b. Modify the default style, e.g. set a different font;
c. Save the file as template using menu File -> Templates -> Save as template

2. Set as default template:
-> Menu File -> Templates -> Manage, select your template, "Set as default" button.

3. Verify that Calc knows and applies the new default template:
-> Close and re-open Calc. The new file should use the custom style set in step 1.c.

4. Open a CSV file with Calc. Calc won't use the custom style set in step 1.c. -> Problem!

There are some workarounds (see http://superuser.com/questions/302107/how-to-set-the-default-font-in-libreoffice-calc/302133#302133 at the end), but it would be nice if Calc would apply custom templates in a consistent way.
Comment 1 Joel Madero 2014-11-16 20:19:38 UTC
Ubuntu 14.10 x64
LibreOffice release

Confirmed (NEW)
Minor - slows down professional quality work but does not prevent it.
Low - default for minor bugs.

(please don't change the severity/importance without knowing what they are used for).

It would be good to upload a csv file so it's faster to test this.

Thanks for reporting! Indeed a little frustrating.
Comment 2 FS 2014-11-17 12:31:46 UTC
Created attachment 109614 [details]
Example CSV file for testing

Sample CSV file added to ease testing.
Comment 3 Aprax 2015-09-17 08:42:41 UTC
I can confirm that the Options > LibreOffice > Fonts doesn't respect the Font Settings for HTML, Basic and SQL Sources.

Even though I've specified that Times New Roman should be used with Size = 8, it consistenly uses Liberation Sans and the result is HUGE characters.

I've also tried using the Replacement Table to convert Liberation Sans to Times New Roman but this doesn't work either.

In my case, I have an sql database from which I want to extract rows of data from a specific table to a csv file (there's no option for an ods file). 
Each day a scheduled job performs the extaction and then clears the data from the table, I open the csv and copy data for that day and 'Paste Special' without formats into an odt file which uses Times New Roman 8 point.

The amount of data (columns & rows) is small so the HUGE font is not a big problem, it's just irritating.
It would be much nicer if the csv file used the TNR 8 point format.
Comment 4 Quazgar 2017-07-06 17:42:44 UTC
Relevant ask.lo.org questions, sometimes with workaround as proposed answer:
- https://ask.libreoffice.org/en/question/3256/
- https://ask.libreoffice.org/en/question/27342/
- https://ask.libreoffice.org/en/question/108336/
Comment 5 Tux 2017-07-11 07:28:50 UTC
This is still the case in 40m0

Though this is no major bug, it really slows down my work. (re)generating CSV files and checking them in LO (using the Reload functionality) will reset the font to something non-sensible on every reload.

Could we al least have an option to NOT change the font settings on reload please?
Comment 6 QA Administrators 2018-07-21 02:39:26 UTC Comment hidden (obsolete)
Comment 7 FS 2018-07-21 16:49:31 UTC
Still present in Version: (x64)
Build-ID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
Comment 8 QA Administrators 2019-07-22 02:44:14 UTC
Dear FS,

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 with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

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) from 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team