goffice issueshttps://gitlab.gnome.org/GNOME/goffice/-/issues2023-03-29T18:38:00Zhttps://gitlab.gnome.org/GNOME/goffice/-/issues/67Visual Analysis of Data (add level)2023-03-29T18:38:00ZCarlos SilvestreVisual Analysis of Data (add level)Hello,
This is not really an issue but a feature request to add to the charts under trend line to data category. The level of the chart is the mean level line for a series of measures drawn horizontally. This type of visual analysis pr...Hello,
This is not really an issue but a feature request to add to the charts under trend line to data category. The level of the chart is the mean level line for a series of measures drawn horizontally. This type of visual analysis provides an easy to see summary of the average performance within a condition.
The chart below illustrates classroom participation under baseline, rewards, rewards removed, and return to rewards condition. The horizontal line drawn across the data path adds a visual aid to interpret the data.
![trendline_level](/uploads/341b4b17a71f7e3feb7b37ed9639b901/trendline_level.png)
The current workaround to draw the level consist of creating:
- a new serie(s),
- selecting the data range for X and Y axis that contains the average summary (e.g., baseline session 1 & 5 have average = 1.4) ![level_workbook_setup](/uploads/4fb055ad645b85e605f5c3c4778b4244/level_workbook_setup.png)
- removing the markers from the data points
- selecting skip invalid data to draw the line between the two data points.
Added the workbook below with the sample data.
[Visual_Analysis_of_Data.gnumeric](/uploads/bb87e249f1ea4c66d557e74c0987e2d5/Visual_Analysis_of_Data.gnumeric)https://gitlab.gnome.org/GNOME/goffice/-/issues/66Histogram generates expected results, but only graphs first data series2023-03-31T22:29:26ZCharles HowesHistogram generates expected results, but only graphs first data seriesA histogram plot of two data series should show both of them on the graph, but it's only showing the first. The second data series does show up on the histogram sheet; the generated graph does have two series listed in the properties, b...A histogram plot of two data series should show both of them on the graph, but it's only showing the first. The second data series does show up on the histogram sheet; the generated graph does have two series listed in the properties, but only one is visible.
![gnumeric-error](/uploads/25b672bcbab9cf74c9e9826222609c0c/gnumeric-error.png)
Also, it's not showing the labels even though the 'Labels' checkbox was checked.
And it's not possible to add a series to the histogram.
I deleted series2, and it was removed. When I then deleted series1, gnumeric crashed.
This is just a guess, but it looks like the histogram plot is hardcoded to only accept one series.
This is gnumeric-1.12.55 on Fedora 37
The coredump was reported to bugzilla here: https://bugzilla.redhat.com/show_bug.cgi?id=2182192https://gitlab.gnome.org/GNOME/goffice/-/issues/62Improve integer powers of 10 - ( relevant for rounding, truncing, flooring .....2023-06-08T20:14:50Zb. s.Improve integer powers of 10 - ( relevant for rounding, truncing, flooring ... and thus for nearly all math )If use of some mem- and disk-space is tolerable I'd propose to enlarge the pow10-tables in goffice/goffice/math/go-math.c/pow10 and ~pow10l.
pro: speedy and correct integer powers of ten. ( As of now gnumeric-long-std. has some 800++ f...If use of some mem- and disk-space is tolerable I'd propose to enlarge the pow10-tables in goffice/goffice/math/go-math.c/pow10 and ~pow10l.
pro: speedy and correct integer powers of ten. ( As of now gnumeric-long-std. has some 800++ fails among ~9800 powers, see attached sheets. )
[powers by 'power( 10, i )' - t0613d_power10.gnumeric](/uploads/7bbcddf22cb0dee7f98d472f9c30bdf2/t0613d_power10.gnumeric)
[powers by '10^i' - t0613e_power10.gnumeric](/uploads/b9632ad2368f91adaf49232f54217307/t0613e_power10.gnumeric)
patches see below, change goffice/goffice/math/go-math.c and re- 'make', re- 'make install' of goffice is sufficient to get them into effect.
[table_for_pow10.txt](/uploads/d5b83e0617c6e79f6ea7924dfc2c652b/table_for_pow10.txt)
[table_for_pow10l.txt](/uploads/7b5633a7ecc70387235b2ab1d0c88b48/table_for_pow10l.txt)
contra: the patches boost go-math.o from ~85,056 to ~318,184 bytes. evtl. someone can make the loading conditional acc. the datatype in use?
[edit 2022-10-11 subject and tests]
<details><summary>additional thoughts and explanation: Click to expand</summary>
motivation and impact: Morten made [go_pow10: improve accuracy.](https://gitlab.gnome.org/GNOME/goffice/-/commit/bcf6d9dda47e8bbe3f5e20bb46033e4db90bb407) for gnumeric issue #591, [deco-Math project, step 00_a: exact bin and dec 'ranges' (in gnumeric). - enhancement request -](https://gitlab.gnome.org/GNOME/gnumeric/-/issues/591).
That doesn't cover the full range of values, as I consider correct powers important reg. use in other corrective functions I added some 'string-math improved' powers in goffice and worked with them for some time.
With below tests I saw them slow by ~1.5 sec. vs. ~1.0 sec. in std.-gnumeric. ( The tests calculate some ~75k powers and respond with the time it took to re-calculate the sheets. Place the sample sheets in a new subdir 'deco-math' in 'samples' to run the tests. )
( don't be surprised about the somewhat weak performance of my system, it completely runs from an USB stick. )
[testing and timing 'power( 10, x )' - t0613d-power10.pl](/uploads/8c6682708ce2545ff4398a67e3767848/t0613d-power10.pl)
[testing and timing '10^x' - t0613e-power10.pl](/uploads/305aedd8096a0068ff52b3319e87cd39/t0613e-power10.pl)
I tried to enlarge the tables and see competitive speed while only one binary wasting some space.
There is some stray in the timing results, but I see them precise enough to have '10^i' a little faster than 'power( 10, i )' in most tries - longer code path - and see the patched tables sometimes a little but neglectable slower than c-code 'pow', but with better accuracy.
Made a new issue as the original question was in git-gnumeric and I found no issue# in goffice corresponding to the patch from Morten.
</details>https://gitlab.gnome.org/GNOME/goffice/-/issues/44Gtk4 port2019-12-11T02:34:10ZHubert FiguièreGtk4 portgoffice will need a gtk port to be usable in Gtk4... or to allow porting current app that uses it to Gtk4.
(in my case it's AbiWord)goffice will need a gtk port to be usable in Gtk4... or to allow porting current app that uses it to Gtk4.
(in my case it's AbiWord)https://gitlab.gnome.org/GNOME/goffice/-/issues/40Scaling of values on axis2018-05-22T13:08:56ZBugzillaScaling of values on axis## Submitted by Morten Welinder
**[Link to original bug (#748295)](https://bugzilla.gnome.org/show_bug.cgi?id=748295)**
## Description
Created attachment 302145
xlsx Sample
XL has the ability to scale numbers shown on axes.
For ex...## Submitted by Morten Welinder
**[Link to original bug (#748295)](https://bugzilla.gnome.org/show_bug.cgi?id=748295)**
## Description
Created attachment 302145
xlsx Sample
XL has the ability to scale numbers shown on axes.
For example, if the data has units of micrograms then XL can show 50 for
50ug instead of 5e-5.
Their gui is clunky: you can either pick from a predefined list containing
only positive powers of ten, or you can enter a unit. The ability to enter
a value is not at all obvious.
LO does not appear to have this abilty.
I don't think we can currently do this, but I think we should. We can
currently fake it for certain units:
* For 10^(3n) we can use $n$ comma scaling operators in the format.
* For 10^(-2) we can use percent in format, but "%" will be visible.
**Attachment 302145**, "xlsx Sample":
[yunits.xlsx](/uploads/de4cb8b7fb7e5031aa7546db555f1a7f/yunits.xlsx)
Version: GIThttps://gitlab.gnome.org/GNOME/goffice/-/issues/39Feature request: Display of graph legend spread on multiple axis2018-05-22T13:08:39ZBugzillaFeature request: Display of graph legend spread on multiple axis## Submitted by car..@..web.de
**[Link to original bug (#734178)](https://bugzilla.gnome.org/show_bug.cgi?id=734178)**
## Description
Created attachment 282337
standard configuration of axis
Hi everybody,
I would like to know if ...## Submitted by car..@..web.de
**[Link to original bug (#734178)](https://bugzilla.gnome.org/show_bug.cgi?id=734178)**
## Description
Created attachment 282337
standard configuration of axis
Hi everybody,
I would like to know if it is possible in gnumeric to attach the
symbol coding of a line in a graph (legend) directly to the axis on
which it is displayed? This would be a very useful feature for graphs
with multiple lines and axis, which tend to be confusing with a legend
of all the lines below or somewhere in the graph. To illustrate the
question, I've attached two pictures: One with the standard setting of
gnumeric (graph standard) and one with the feature that I'm looking
for (graph mod).
Best regards
Jakob
**Attachment 282337**, "standard configuration of axis":
![graph-standard](/uploads/aa13b01e4317e92a618ae9d32af6bd8e/graph-standard.png)https://gitlab.gnome.org/GNOME/goffice/-/issues/37Goffice 0.12 A[PB]I Breaks2018-05-22T13:07:42ZBugzillaGoffice 0.12 A[PB]I Breaks## Submitted by Morten Welinder
**[Link to original bug (#698100)](https://bugzilla.gnome.org/show_bug.cgi?id=698100)**
## Description
goc_item_get_style_context should use a class member not hang
the style context on the object.
V...## Submitted by Morten Welinder
**[Link to original bug (#698100)](https://bugzilla.gnome.org/show_bug.cgi?id=698100)**
## Description
goc_item_get_style_context should use a class member not hang
the style context on the object.
Version: GIThttps://gitlab.gnome.org/GNOME/goffice/-/issues/36Change of axis span with mouse2018-05-22T13:07:32ZBugzillaChange of axis span with mouse## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#697089)](https://bugzilla.gnome.org/show_bug.cgi?id=697089)**
## Description
It would be helpful to be able to change an axis span with the mouse, by dragging t...## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#697089)](https://bugzilla.gnome.org/show_bug.cgi?id=697089)**
## Description
It would be helpful to be able to change an axis span with the mouse, by dragging the extremities of the axis.
Currently, this interface is dedicated to the change of axis scale. The axis scale could be modified with a mouse scroll when the pointer is above the axis.
Version: GIThttps://gitlab.gnome.org/GNOME/goffice/-/issues/35implement PlotPolarContour2018-05-22T13:07:22ZBugzillaimplement PlotPolarContour## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#693819)](https://bugzilla.gnome.org/show_bug.cgi?id=693819)**
## Description
Contours plots are available for XYPlots and they would be useful for Polar Plots t...## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#693819)](https://bugzilla.gnome.org/show_bug.cgi?id=693819)**
## Description
Contours plots are available for XYPlots and they would be useful for Polar Plots too.
Version: GIThttps://gitlab.gnome.org/GNOME/goffice/-/issues/34data labels in Polar Plots2018-05-22T13:07:10ZBugzilladata labels in Polar Plots## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#693809)](https://bugzilla.gnome.org/show_bug.cgi?id=693809)**
## Description
Data labels in Polar Plots, as is currently implemented in XYPlots, would be helpfu...## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#693809)](https://bugzilla.gnome.org/show_bug.cgi?id=693809)**
## Description
Data labels in Polar Plots, as is currently implemented in XYPlots, would be helpful.
Version: GIThttps://gitlab.gnome.org/GNOME/goffice/-/issues/33Refresh of country/currency strings in /goffice/utils/formats.c2018-05-22T13:06:50ZBugzillaRefresh of country/currency strings in /goffice/utils/formats.c## Submitted by Chris Leonard
**[Link to original bug (#682810)](https://bugzilla.gnome.org/show_bug.cgi?id=682810)**
## Description
Refresh of country/currency strings
This listing should be refreshed from ISO4217, last done 2010/...## Submitted by Chris Leonard
**[Link to original bug (#682810)](https://bugzilla.gnome.org/show_bug.cgi?id=682810)**
## Description
Refresh of country/currency strings
This listing should be refreshed from ISO4217, last done 2010/08/12.
I'm willing to take a shot at providing a patch for this i18n enhancement, but thought it best to file a ticket because of possible linkage to #682749
../goffice/utils/formats.c:382
United Arab Emirates, Dirhams
to
../goffice/utils/formats.c:557
Zimbabwe, Zimbabwe Dollars
I could easily imagine that this currency listing interacts with the locale picker from ../goffice/gtk/go-locale-sel.c
Locale update is the subject of #682749
https://bugzilla.gnome.org/show_bug.cgi?id=682749
It is likely that these two patches should be landed in a coordinated fashion.https://gitlab.gnome.org/GNOME/goffice/-/issues/32Label an axis for easy recognition2018-05-22T13:06:32ZBugzillaLabel an axis for easy recognition## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#669255)](https://bugzilla.gnome.org/show_bug.cgi?id=669255)**
## Description
Currently, when creating a chart with many axes, it is not easy to deal with them b...## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#669255)](https://bugzilla.gnome.org/show_bug.cgi?id=669255)**
## Description
Currently, when creating a chart with many axes, it is not easy to deal with them because they are only labelled AxeY1, AxeY2, etc. It would be easier to have meaningful labels.
I see two possible solutions:
1) either we create a field with a label
2) or with use the title of the axis
Version: GIThttps://gitlab.gnome.org/GNOME/goffice/-/issues/313DXYZbarchart2018-05-22T13:06:22ZBugzilla3DXYZbarchart## Submitted by oli..@..il.com
**[Link to original bug (#657913)](https://bugzilla.gnome.org/show_bug.cgi?id=657913)**
## Description
Created attachment 195371
3DXYZbarchart from sigmaplus grapher
Hi everybody (specially Jean :)),
...## Submitted by oli..@..il.com
**[Link to original bug (#657913)](https://bugzilla.gnome.org/show_bug.cgi?id=657913)**
## Description
Created attachment 195371
3DXYZbarchart from sigmaplus grapher
Hi everybody (specially Jean :)),
I find 3DXYZbarchart very classy and permit very pedagogical charts, when pasted on maps. Surely, very difficult to implement...
**Attachment 195371**, "3DXYZbarchart from sigmaplus grapher":
![3DXYZbarchart_from_sigmaplus_grapher](/uploads/0b312a8b9489456af950dfc8e16fda00/3DXYZbarchart_from_sigmaplus_grapher.gif)https://gitlab.gnome.org/GNOME/goffice/-/issues/30Multicolor palette for surface2018-05-22T13:06:08ZBugzillaMulticolor palette for surface## Submitted by oli..@..il.com
**[Link to original bug (#657907)](https://bugzilla.gnome.org/show_bug.cgi?id=657907)**
## Description
Created attachment 195368
some example from Excel 2003
Hi everybody,
Would it be possible to use...## Submitted by oli..@..il.com
**[Link to original bug (#657907)](https://bugzilla.gnome.org/show_bug.cgi?id=657907)**
## Description
Created attachment 195368
some example from Excel 2003
Hi everybody,
Would it be possible to use some multicolor palette (from theme) on 3D surface chart ?
**Attachment 195368**, "some example from Excel 2003":
![surface3-fixscale](/uploads/f806a42fe495af8bdac8303a1ecd191a/surface3-fixscale.png)https://gitlab.gnome.org/GNOME/goffice/-/issues/29date & time format selector inconsistency2021-03-17T23:34:47ZBugzilladate & time format selector inconsistency## Submitted by Andreas J. Guelzow `@guelzow`
**[Link to original bug (#657463)](https://bugzilla.gnome.org/show_bug.cgi?id=657463)**
## Description
It is somewhat confusing that the combined time/date formats are split between the...## Submitted by Andreas J. Guelzow `@guelzow`
**[Link to original bug (#657463)](https://bugzilla.gnome.org/show_bug.cgi?id=657463)**
## Description
It is somewhat confusing that the combined time/date formats are split between the date and time categories:
Currently we have:
[$-f8fa]m/d/yy h:mm in "Date" category
yyyy-mm-dd hh:mm:ss in "Date" category
yyyy-mm-dd"T"hh:mm:ss"Z" in "Time" category
As a minimum they should all be listed in the same category, but there could a case be made for them to have their own category. (considering that we even seem to have an empty "Special" category.https://gitlab.gnome.org/GNOME/goffice/-/issues/28implement Hodrick–Prescott (H-P) filter as trend line2018-05-22T13:05:47ZBugzillaimplement Hodrick–Prescott (H-P) filter as trend line## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#657112)](https://bugzilla.gnome.org/show_bug.cgi?id=657112)**
## Description
see title## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#657112)](https://bugzilla.gnome.org/show_bug.cgi?id=657112)**
## Description
see titlehttps://gitlab.gnome.org/GNOME/goffice/-/issues/27Implement Sankey diagramm2018-05-22T13:05:32ZBugzillaImplement Sankey diagramm## Submitted by oli..@..il.com
**[Link to original bug (#654535)](https://bugzilla.gnome.org/show_bug.cgi?id=654535)**
## Description
Hello every Gnumeric contributors,
What do you think about implementing a Sankey chart ?
It's a c...## Submitted by oli..@..il.com
**[Link to original bug (#654535)](https://bugzilla.gnome.org/show_bug.cgi?id=654535)**
## Description
Hello every Gnumeric contributors,
What do you think about implementing a Sankey chart ?
It's a chart to represent flows.
Maybe very difficult to code :/
Version: GIThttps://gitlab.gnome.org/GNOME/goffice/-/issues/26It is not possible to revert to an automatic style2018-05-22T13:05:24ZBugzillaIt is not possible to revert to an automatic style## Submitted by an unknown user
**[Link to original bug (#644497)](https://bugzilla.gnome.org/show_bug.cgi?id=644497)**
## Description
Make a simple pie plot with at least two values. By default, there are two colors used, one for e...## Submitted by an unknown user
**[Link to original bug (#644497)](https://bugzilla.gnome.org/show_bug.cgi?id=644497)**
## Description
Make a simple pie plot with at least two values. By default, there are two colors used, one for each value. Now, change the series back color. There is no way (at least I'm unable to find one) to revert to the default. All colors are the same for ever.
There are several possible solutions:
- don't allow color changes when the vary-by-element flags is set;
- add a button or a check box to revert to default;
- check if the set value is the default after each change.
The third solution might be a bit tricky to implement. I prefer the second.
Any other opinion?https://gitlab.gnome.org/GNOME/goffice/-/issues/25more smoothing filters in graphs2018-05-22T13:05:13ZBugzillamore smoothing filters in graphs## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#635624)](https://bugzilla.gnome.org/show_bug.cgi?id=635624)**
## Description
Please implement more smoothing filters in graphs, e.g. double exponential smoothin...## Submitted by Frédéric Parrenin `@parrenin`
**[Link to original bug (#635624)](https://bugzilla.gnome.org/show_bug.cgi?id=635624)**
## Description
Please implement more smoothing filters in graphs, e.g. double exponential smoothing, Holt's trend corrected exponential smoothing and Additive and Muliplicative Holt-Winters exponential smoothing. Thanks in advance.
Version: GIThttps://gitlab.gnome.org/GNOME/goffice/-/issues/24Need for a way to know the natural size of any object.2018-05-22T13:04:59ZBugzillaNeed for a way to know the natural size of any object.## Submitted by Jon Nordby
**[Link to original bug (#629794)](https://bugzilla.gnome.org/show_bug.cgi?id=629794)**
## Description
By "natural size" I mean the size the rendered model will occupy if there are no external restrictions...## Submitted by Jon Nordby
**[Link to original bug (#629794)](https://bugzilla.gnome.org/show_bug.cgi?id=629794)**
## Description
By "natural size" I mean the size the rendered model will occupy if there are no external restrictions on its size.
Steps to reproduce:
1) Create a graph widget with GogAreaPlot. Add it to a GtkWindow
2) Add legend and populate with data
3) Note that when running, making the window (and thus the allocation for the widget) big enough will result in the legend being shown with all legend items in one row. The legend will then have a certain height X just a bit smaller than the window height. Increasing the window height further will not influence X.
4) Get a renderer for the graph view, update it with gog_renderer_update.
5) Get the view of the legend, and use gog_view_size_request() with (constant) very large sizes for the "available" attribute. Note that at the moment, you will need to modify gog_renderer_update from destroying the renderer surface (last two lines).
Expected results:
Height of the "required" GogViewRequisition equal to X, the height the legend had when the available area in the window was big enough. This should be independent of the size of the window the graph widget is in (as the sizes given to the renderer/view are not related to it).
Actual results:
Height that depends on the window height. Works fine for available height bigger than X. For available heights slightly smaller than X it seems to almost work (the value is a bit low, but does not seem to be a relation to the actual window size). For small window heights it seems to return the height of the window.
### Blocking
* [Bug 647218](https://bugzilla.gnome.org/show_bug.cgi?id=647218)