gnumeric issueshttps://gitlab.gnome.org/GNOME/gnumeric/-/issues2018-05-22T13:19:04Zhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/70help > Live Assistance behavior with no irc: handler.2018-05-22T13:19:04ZBugzillahelp > Live Assistance behavior with no irc: handler.## Submitted by A
**[Link to original bug (#392891)](https://bugzilla.gnome.org/show_bug.cgi?id=392891)**
## Description
clicking on help > Live Assistance, nothing happens
Version: 1.10.x## Submitted by A
**[Link to original bug (#392891)](https://bugzilla.gnome.org/show_bug.cgi?id=392891)**
## Description
clicking on help > Live Assistance, nothing happens
Version: 1.10.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/69Ctrl/Z does not work when a chart is selected2018-05-22T13:18:57ZBugzillaCtrl/Z does not work when a chart is selected## Submitted by Vladimir Chukharev
**[Link to original bug (#387853)](https://bugzilla.gnome.org/show_bug.cgi?id=387853)**
## Description
+++ This bug was initially created as a clone of Bug #338619 +++
Ctrl/Z does not work when a ...## Submitted by Vladimir Chukharev
**[Link to original bug (#387853)](https://bugzilla.gnome.org/show_bug.cgi?id=387853)**
## Description
+++ This bug was initially created as a clone of Bug #338619 +++
Ctrl/Z does not work when a chart is selected. I did not check
redo and other hot keys...
Version: 1.7.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/68Statistics need cross tabulation2018-05-22T13:18:46ZBugzillaStatistics need cross tabulation## Submitted by Frederik Elwert
**[Link to original bug (#384727)](https://bugzilla.gnome.org/show_bug.cgi?id=384727)**
## Description
One of Gnumeric's advanced features is the set of statistical precedures available from the stati...## Submitted by Frederik Elwert
**[Link to original bug (#384727)](https://bugzilla.gnome.org/show_bug.cgi?id=384727)**
## Description
One of Gnumeric's advanced features is the set of statistical precedures available from the statistics menu. But I think that one basic and important feature is missing here: crosstablulation.
In many aspects, Gnumeric can serve as a replacement for SPSS and the like for users who need only basic statistical features. But for descriptive analysis, cross tabulation is often crucial. So I think Gnumeric needs at least some simple contingency table similar to R's "table" command.
Some sort of advances output with row/col percentage or an integrated chi square test would be nice.
Version: 1.6.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/67Localize all function names2018-05-22T13:18:03ZBugzillaLocalize all function names## Submitted by Christian Neumair
Assigned to **Christian Neumair**
**[Link to original bug (#381564)](https://bugzilla.gnome.org/show_bug.cgi?id=381564)**
## Description
The attached patch is hopefully a large step towards correc...## Submitted by Christian Neumair
Assigned to **Christian Neumair**
**[Link to original bug (#381564)](https://bugzilla.gnome.org/show_bug.cgi?id=381564)**
## Description
The attached patch is hopefully a large step towards correctly localized functions.
It adds localization caps to gnumeric expression serialization routines, assigns all function-related strings to the "gnumeric-functions" package. I also tried to ensure that all backend-related functions don't use translation (i.e. storage-related), while all user input parsers should support localized function names, and all user-output should be localized.
Review appreciated.
TODO
* Do throughout testing
* Support localized output in string-to-columns (STF)
* Port all functions to a sane GnmFuncHelp layout
* Correct po/POTFILES, po/POTFILES to include/exclude the relevant plugin and builtin function source files
* Merge previous po/*.po translations to po-functions/*.po
Because the last two items are Danilo's area of expertise, I'm CCing him.
I'm also making this bug report depend on [bug 312986](https://bugzilla.gnome.org/show_bug.cgi?id=312986), [bug 312746](https://bugzilla.gnome.org/show_bug.cgi?id=312746) as they contain precious hints how we can improve the GnmFuncHelp descriptions.
Version: git master
### Depends on
* [Bug 312746](https://bugzilla.gnome.org/show_bug.cgi?id=312746)
* [Bug 312986](https://bugzilla.gnome.org/show_bug.cgi?id=312986)https://gitlab.gnome.org/GNOME/gnumeric/-/issues/66Beyond Excel Feature: type coercion or "force cell data to a particular type"2018-05-22T13:17:48ZBugzillaBeyond Excel Feature: type coercion or "force cell data to a particular type"## Submitted by Bryce Nesbitt
**[Link to original bug (#365062)](https://bugzilla.gnome.org/show_bug.cgi?id=365062)**
## Description
This is a feature request, something I don't get of of Excel, but hope one day Gnumeric can do.
Fr...## Submitted by Bryce Nesbitt
**[Link to original bug (#365062)](https://bugzilla.gnome.org/show_bug.cgi?id=365062)**
## Description
This is a feature request, something I don't get of of Excel, but hope one day Gnumeric can do.
Frequently I have messy spreadsheets to deal with. Often there will be some text that looks like a date, or a number, but is not.
The feature I'd like is a checkbox to "force" the data in a particular cell to be of a particular type. If the data can't be coerced(e.g. "2006-Julyyy-01"), then Gnumeric should complain or highlight the cell.
This will save time: because converting formats cell-by-cell is hard, especially when there are thousands of them.
This will save errors: because you can get wrong results if the type of data is not what you expect (for example: text sometimes calculates as zero in a numeric expression).
Version: 1.7.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/65clipboard, gnumeric format: problem with absolute addresses.2018-05-22T13:17:37ZBugzillaclipboard, gnumeric format: problem with absolute addresses.## Submitted by an unknown user
**[Link to original bug (#360849)](https://bugzilla.gnome.org/show_bug.cgi?id=360849)**
## Description
Enter the following data:
A1: 1
A2: 2
A3: =$A$1+$A$2 3 is displayed
Select A1:A3 and copy to cli...## Submitted by an unknown user
**[Link to original bug (#360849)](https://bugzilla.gnome.org/show_bug.cgi?id=360849)**
## Description
Enter the following data:
A1: 1
A2: 2
A3: =$A$1+$A$2 3 is displayed
Select A1:A3 and copy to clipboard.
Start another gnumeric process. Place cursor in B1 and paste. 0 is displayed in B3, and the cell contains =$A$1+$A$2, exactly as in the source.
This behaviour is the same for pasting between two different gnumerics over the X or Windows clipboard, and between two workbooks in the same gnumeric process.
You asked for it, you got it, but this makes no sense. The formula has nothing to do with A1 and A2 in the *destination* sheet.
There are three interpretations that *would* make sense.
a) Refer to A1 and A2 in the source sheet/workbook. Sometimes, this would be
what the user intended, but probably not most of the time. There are too many
problems to make this the default: What do we do with sources which haven't
been written to disk? Moving either the source or the destination workbook
would break stuff, etc.
b) Transform absolute references to cells inside the source range to absolute
references to cells in the destination. In this case: =$B$1+$B$2
c) Replace absolute references outside the source range with their values. So B3
would become =1+2 or 3.
b) may be closest to what the user expects, but c) would also be better than what we are doing now.
This is closely related to the issue in 360666: dependencies not taken into account when exporting via clippboard.
OpenCalc is no better than Gnumeric in this respect. $A$1 in the source becomes $A$1 in the dest.
You see one consequence of this in charts. When you build them by marking data and using the wizard, data series have absolute addresses. So if you mark a chart and all the data it is based on, and paste it into another gnumeric, the copy of the chart will look nothing like the original. Unless you happen to paste it into the same cell in the destination.
One final twist: When copying charts, there is a difference between copying between two gnumerics and between two workbooks in the same gnumeric. Between gnumerics, the data series 'Sheet1!$A$1:$A$3' is copied unchanged. Between workbooks in the same gnumeric, a reference to the source workbook is added:
'[../../../home/jk/gnome/chart.gnumeric]Sheet1!$A$1:$A$3'. I.e. solution a) above. This is fragile!
Version: git masterhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/64database functions' criteria should allow references2018-05-22T13:17:17ZBugzilladatabase functions' criteria should allow references## Submitted by A
**[Link to original bug (#360844)](https://bugzilla.gnome.org/show_bug.cgi?id=360844)**
## Description
criteria for the database functons (dget, dmax dmin etc..) should allow the use of references to other cells.
...## Submitted by A
**[Link to original bug (#360844)](https://bugzilla.gnome.org/show_bug.cgi?id=360844)**
## Description
criteria for the database functons (dget, dmax dmin etc..) should allow the use of references to other cells.
Version: 1.10.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/63Text orientation: multiline2018-05-22T13:17:06ZBugzillaText orientation: multiline## Submitted by rafa
**[Link to original bug (#358757)](https://bugzilla.gnome.org/show_bug.cgi?id=358757)**
## Description
Please describe the problem:
When I set the angle of a cell at -90º, if text is longer than the height of th...## Submitted by rafa
**[Link to original bug (#358757)](https://bugzilla.gnome.org/show_bug.cgi?id=358757)**
## Description
Please describe the problem:
When I set the angle of a cell at -90º, if text is longer than the height of the cell it do not appear as multiline; text disappear over the cell. I try solve it change the align options but I do not obtain nothing.
Steps to reproduce:
1. Select a cell with long text
2. Format cell
3. Align
4. orientation angle -90 degrees
Actual results:
Text invade other cells or if configures align options text disappear over the cell.
Expected results:
Cell would appear as multiline and show completely the content of the cell.
Does this happen every time?
Yes
Other information:
Sorry for my English. If you do not understand the problem I can try to send you some screenshots. Thank you for your work.
Version: 1.6.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/62Improve function classification2018-05-22T13:16:52ZBugzillaImprove function classification## Submitted by Luke Hutchison `@lukehutch`
**[Link to original bug (#352893)](https://bugzilla.gnome.org/show_bug.cgi?id=352893)**
## Description
In "Insert->Function", permut() is in the list of functions under "statistics", but c...## Submitted by Luke Hutchison `@lukehutch`
**[Link to original bug (#352893)](https://bugzilla.gnome.org/show_bug.cgi?id=352893)**
## Description
In "Insert->Function", permut() is in the list of functions under "statistics", but combin() is not. You have to view all functions to see it.
Version: 1.6.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/61License documents with Creative Commons2018-05-22T13:16:45ZBugzillaLicense documents with Creative Commons## Submitted by Jaime Frutos Morales
**[Link to original bug (#349220)](https://bugzilla.gnome.org/show_bug.cgi?id=349220)**
## Description
It would be great if documents created with Gnumeric could be licensed under a Creative Comm...## Submitted by Jaime Frutos Morales
**[Link to original bug (#349220)](https://bugzilla.gnome.org/show_bug.cgi?id=349220)**
## Description
It would be great if documents created with Gnumeric could be licensed under a Creative Commons license when you save them for the first time. Properties page should show the kind of license and maybe a link to the license deed.
Microsoft has already developed a addon for Office doing this, so maybe export method should be aware of CC license as well.
Info about this:
http://wiki.creativecommons.org/Embedding_Specifications
http://wiki.creativecommons.org/Microsoft_Office_Document_Formats
http://wiki.creativecommons.org/Microsoft_Office_Addinhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/60col/row auto-sizing ignores merged regions with 1 col/row2018-05-22T13:16:25ZBugzillacol/row auto-sizing ignores merged regions with 1 col/row## Submitted by Tomas Pospisek
**[Link to original bug (#345861)](https://bugzilla.gnome.org/show_bug.cgi?id=345861)**
## Description
Please describe the problem:
If you resize a row by doubleclicking on a line separating two rows t...## Submitted by Tomas Pospisek
**[Link to original bug (#345861)](https://bugzilla.gnome.org/show_bug.cgi?id=345861)**
## Description
Please describe the problem:
If you resize a row by doubleclicking on a line separating two rows the resulting row size will be too small. I.e. not big enoough to be able to display all lines withing a cell inside such a row.
Steps to reproduce:
1. load the attached gnumeric sheet
2. double-click on the line separating the "1" and "2" widgets
Actual results:
The first row is resized too small, so that you can't read the second line in the cell.
Expected results:
The row should be resized in a way so that all the text inside the cell can be read. (Something like: size_of_row = number_of_lines * size_of_line + border_size)
Does this happen every time?
yes
Other information:
See gnumeric sheet at http://sourcepole.ch/tpo/tmp/kak.gnumeric
Version: git masterhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/59add pref to change default save format on a per-user basis2018-05-22T13:16:14ZBugzillaadd pref to change default save format on a per-user basis## Submitted by Chris Rebert
**[Link to original bug (#345856)](https://bugzilla.gnome.org/show_bug.cgi?id=345856)**
## Description
Provide an option in the Preferences window that allows one to choose the default file format to sav...## Submitted by Chris Rebert
**[Link to original bug (#345856)](https://bugzilla.gnome.org/show_bug.cgi?id=345856)**
## Description
Provide an option in the Preferences window that allows one to choose the default file format to save in (probably via a listbox) and changes the plugins' default_saver_priority accordingly.
Version: 1.6.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/58[xls] INDEX problem2018-05-22T13:15:54ZBugzilla[xls] INDEX problem## Submitted by Ivan Wong
**[Link to original bug (#343176)](https://bugzilla.gnome.org/show_bug.cgi?id=343176)**
## Description
Loading the attached XLS file gives the following messages:
Reading file:///tmp/4.xls
Excel 97 +
Emplo...## Submitted by Ivan Wong
**[Link to original bug (#343176)](https://bugzilla.gnome.org/show_bug.cgi?id=343176)**
## Description
Loading the attached XLS file gives the following messages:
Reading file:///tmp/4.xls
Excel 97 +
Employees!L2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!L2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!M2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!M2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!N2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!N2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!O2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!O2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!P2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!P2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!Q2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!Q2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!R2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!R2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!AC2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!AC2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!AD2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!AD2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!AE2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!AE2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!AF2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!AF2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!AG2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!AG2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!AH2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!AH2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Employees!AI2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3A
Employees!AI2 : Hmm, ptgAttr of type 0 ??
I've seen a case where an instance of this with flag A and another with flag 3
bracket a 1x1 array formula. please send us this file.
Flags = 0x3
Version: git masterhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/57Addition of styles for formatting cells2023-04-16T03:56:15ZBugzillaAddition of styles for formatting cells## Submitted by Dov Grobgeld
**[Link to original bug (#340904)](https://bugzilla.gnome.org/show_bug.cgi?id=340904)**
## Description
The current method of formatting cells in Gnumeric resembles the use of formatting elements in HTML ...## Submitted by Dov Grobgeld
**[Link to original bug (#340904)](https://bugzilla.gnome.org/show_bug.cgi?id=340904)**
## Description
The current method of formatting cells in Gnumeric resembles the use of formatting elements in HTML in the early days before the introduction of style sheets. I.e. there is no semantic markup of the cells, e.g. to say that a cell contains a header size 1, but instead the fontsize, and color must be set explicitely. A more modern approach would be to allow the "style" of a cell to be set and then attach a style sheet with the corresponding mapping of the style name to font, colors etc.
Here is a rough draft of possible GUI support for such an idea:
1. Add a Format/Workbook/Stylesheet notebook page that contains a GtkTreeView list of all defined styles.
2. In the right click/Format notebook, add a page Style in which contains a list of all defined styles in the workbook. As in HTML, setting the color or font explicitely should override the style setting.
Just wondering, does the ODF support such use of style sheets?https://gitlab.gnome.org/GNOME/gnumeric/-/issues/56External references only work between open workbooks2018-05-22T13:15:18ZBugzillaExternal references only work between open workbooks## Submitted by Tammo Spalink
**[Link to original bug (#340456)](https://bugzilla.gnome.org/show_bug.cgi?id=340456)**
## Description
Please describe the problem:
With two books (Book1 and Book2) open, it is possible to reference fro...## Submitted by Tammo Spalink
**[Link to original bug (#340456)](https://bugzilla.gnome.org/show_bug.cgi?id=340456)**
## Description
Please describe the problem:
With two books (Book1 and Book2) open, it is possible to reference from one to
the other -- e.g. have a cell in Book1 with formula '=[Book2.gnumeric]Sheet1!A1'
that resolves correctly.
Close Book2 however, and the formula is clobbered with #REF...
Steps to reproduce:
1.
2.
3.
Actual results:
Expected results:
Does this happen every time?
Other information:
Version: git masterhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/55No auto-completion with F2 editing2018-05-22T13:15:09ZBugzillaNo auto-completion with F2 editing## Submitted by Sven Herzberg
**[Link to original bug (#338698)](https://bugzilla.gnome.org/show_bug.cgi?id=338698)**
## Description
If I select a cell and start typing text, gnumeric provides a completion suggestion based upon the ...## Submitted by Sven Herzberg
**[Link to original bug (#338698)](https://bugzilla.gnome.org/show_bug.cgi?id=338698)**
## Description
If I select a cell and start typing text, gnumeric provides a completion suggestion based upon the data from the column.
If I press F2 over a cell and start editing text, gnumeric doesn't provide a completion.
IMHO it should provide a completion suggestion for this case too.
Version: 1.6.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/53Scrolling broken for large cells2018-05-22T13:14:46ZBugzillaScrolling broken for large cells## Submitted by Tammo Spalink
**[Link to original bug (#335669)](https://bugzilla.gnome.org/show_bug.cgi?id=335669)**
## Description
Please describe the problem:
If a cell is larger than the gnumeric gui window, it is not possible t...## Submitted by Tammo Spalink
**[Link to original bug (#335669)](https://bugzilla.gnome.org/show_bug.cgi?id=335669)**
## Description
Please describe the problem:
If a cell is larger than the gnumeric gui window, it is not possible to use the
scrollbars to expose all parts of the cell. Instead, scrolling will jump the
view to adjacent cells. Basically, scrolling seems to be measured in terms of
cells instead of displayed pixels... If I have a cell X too tall to fit in my
window (meaning that I cannot see the bottom of the data in this cell) and I
scroll down (even with just one click on the downward scroller button) it will
change the view so that cell X + 1 is aligned with the top of the window. This
means that the bottom of cell X cannot be displayed in any manner that I have
discovered.
Steps to reproduce:
1. Make a cell taller than the GUI window
2. Try to look at the bottom of the cell
3.
Actual results:
The view jumps past the cell in question
Expected results:
I would expect to see the cell itself
Does this happen every time?
Yup
Other information:
Version: 1.6.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/52Insert sheet defaults prefered over gnumeric defaults2018-05-22T13:14:32ZBugzillaInsert sheet defaults prefered over gnumeric defaults## Submitted by Jose Da Silva
**[Link to original bug (#335462)](https://bugzilla.gnome.org/show_bug.cgi?id=335462)**
## Description
Please describe the problem:
I currently have gnumeric set as Helvetica font=9 as a general prefere...## Submitted by Jose Da Silva
**[Link to original bug (#335462)](https://bugzilla.gnome.org/show_bug.cgi?id=335462)**
## Description
Please describe the problem:
I currently have gnumeric set as Helvetica font=9 as a general preference, but
I have a sheet set as Times font=12. When inserting some cells, the new
inserted cells take-on the gnumeric default value of Helvetica font=9 instead
of this particular sheet default which is Times font=12.
I notice that gnumeric 1.6.x (relative to version1.4.2) has fixed the "insert
row of cells" and also fixed the "insert column of cells" but the insert group
of cells is still not fixed or got forgotten during the fixing process.
Just for your info, version 1.4.2 has all the inserts hard-coded to sans
font=10, so I'm glad to know that gnumeric version 1.6.x has improved/fixed the
bug mentioned (except for the insert cells).
Steps to reproduce:
1. Start gnumeric and set the preferences to something other than sans font=10
(I mention this step since version 1.4.2 apparently seemed hardcoded to insert
new cells as sans font=10). Then close gnumeric so that you start step2 with a
fresh gnumeric that selects the new preferred font type.
2. Start gnumeric and select the default sheet cell so that you highlight all
cells on the spreadsheet (top-left above cell A-1).
3. After you highlight all the cells in step 2 above, then on the menu select
"Format->cells" to open the "Format cells menu" and select a default font and
size other than what you set in your gnumeric preferences in step 1, so if step
1 you selected gnumeric preferences of Helvetica font=9, then here you select
sheet preferences of "Times font=12"
4. Insert some random data in a 4x4 grid, for example:
B2=Hello, C2=5, D2=100, E2=Go
B3=7, C3=Hi, D3=Where, E3=6
B4=x, C4=x, D4=y, E4=y
B5=z, C5=z, D5=99, E5=-1.5
5. Using your mouse or cursor keys, select or highlight 2x2 cells at
C3,D3,C4,D4 and then on the menu select "Insert->cells"
6. I usually need to insert a row of data, so I suggest select move data down
when you insert a new 2x2 block within C3,D3,C4,D4
7. If you selected the preferences mentioned in step 3, then look at the cell
attributes and you will note that the inserted cells now are set to the
gnumeric default of Helvetica font=9 instead of the sheet preference of Times
font=12.
Actual results:
The spreadsheet ends up having inserted cells that take on the gnumeric
preferences instead of the sheet defaults which may be set to a default that is
not the same as the normal gnumeric preferences you usually use.
Expected results:
I expected the inserted cells to take on the sheet preferences because the
sheet was set by someone else that has different preferences to what I like.
therefore I would like to insert new cells using their preferences instead of
mine.
Does this happen every time?
It happens with gnumeric 1.4.2 and gnumeric 1.6.x
I am glad to see that version 1.6.x has the "insert column" (example high-light
row B) and "insert row" (example highlight row 2) fixed compared to 1.4.2 but
the only one apparently missed is when you highlight a 1 cell or a group of
cells.
Other information:
I think it is probably a bug instead of a feature since I use another
spreadsheet and the default action is for it to take the sheet preference
instead of the application program default.
For reference, I'm comparing it to the spreadsheet program that shipped with
OS/2warp3. I don't know how other spreadsheets behave in this circumstance, or
if they behave the same way or differently than what is described here.
Thanks!
Version: 1.6.xhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/51Password entry issues, partial data result returned.2018-05-22T13:14:22ZBugzillaPassword entry issues, partial data result returned.## Submitted by Bryce Nesbitt
**[Link to original bug (#335296)](https://bugzilla.gnome.org/show_bug.cgi?id=335296)**
## Description
Please describe the problem:
I ran into the following issues, attempting to read a Postgres or Mysq...## Submitted by Bryce Nesbitt
**[Link to original bug (#335296)](https://bugzilla.gnome.org/show_bug.cgi?id=335296)**
## Description
Please describe the problem:
I ran into the following issues, attempting to read a Postgres or Mysql table
through libgda and Gnumeric:
1) While my database has no password, gnome-database-properties gives "password
required (fe_sendauth: no password supplied)" when I attempt to set a empty
password.
2) Once I set a password, the "Tables and Views" shows only Tables, not any of
my Views.
3) I was unable to add a _ character in a data source name
4) User interface was too microsoft-like
Steps to reproduce:
Actual results:
Expected results:
Does this happen every time?
Other information:
http://www.obviously.com/tech_tips/Loading%20SQL%20Data%20into%20Gnumeric.htmlhttps://gitlab.gnome.org/GNOME/gnumeric/-/issues/50execSQL misbehaviour2018-05-22T13:14:05ZBugzillaexecSQL misbehaviour## Submitted by Bryce Nesbitt
**[Link to original bug (#335295)](https://bugzilla.gnome.org/show_bug.cgi?id=335295)**
## Description
Please describe the problem:
Using Gnumeric 1.6.1 from the SUSE supplimentary distribution,
along w...## Submitted by Bryce Nesbitt
**[Link to original bug (#335295)](https://bugzilla.gnome.org/show_bug.cgi?id=335295)**
## Description
Please describe the problem:
Using Gnumeric 1.6.1 from the SUSE supplimentary distribution,
along with gnome-database-properties 1.3.91 and Postgres 8.0.3.
Also tested with mySQL 4.1.13 with similar results.
Steps to reproduce:
1. Set up a postgres data source in gnome-database-properties
2. Enter array forumula =execSQL("Postgres Test","fishy","fishfish","select
addr1,addr2 from eg_pod limit 6").
3. Use the awful syntax inherited from Excel to execute this: ctrl-shift-enter.
4. Observe that just two rows and one column of valid data are returned. The
rest of the cells get '0'.
Actual results:
Partial data.
Expected results:
All the data.
Does this happen every time?
Yes.
Other information:
Note that it seems to ignore the first three parameters (source, login and
password). And libgda asks me for the password two more times before the data
is returned.
Version: 1.6.x