Good morning,
I'm not sure if the problem is in LibreOffice or something else. Also, I did try to post this in LibreOffice support, but my login does not work, and trying to create a new account does not work.
(Fedora-34, Gnome, LibreOffice 7.1.8.1, HP LaserJet Pro MFP M180nw) I have a LibreOffice Calc spreadsheet. It has a chart. On my workstation monitor, the chart looks as I desire: border, x and y axes, legend, axis labels, data curves, tick marks along the axes, and a grid in the plot area. When I print the chart to a PDF file and then display the PDF file, it look the same as in LibreOffice Calc. But, when in LibreOffice Calc, I print to the printer, there are no axes and no grid lines. How do I get the axes and grid lines to show?
Thank-you in advance. Bill.
On 12/28/21 10:30 AM, home user wrote:
Good morning,
I'm not sure if the problem is in LibreOffice or something else. Also, I did try to post this in LibreOffice support, but my login does not work, and trying to create a new account does not work.
(Fedora-34, Gnome, LibreOffice 7.1.8.1, HP LaserJet Pro MFP M180nw) I have a LibreOffice Calc spreadsheet. It has a chart. On my workstation monitor, the chart looks as I desire: border, x and y axes, legend, axis labels, data curves, tick marks along the axes, and a grid in the plot area. When I print the chart to a PDF file and then display the PDF file, it look the same as in LibreOffice Calc. But, when in LibreOffice Calc, I print to the printer, there are no axes and no grid lines. How do I get the axes and grid lines to show?
Thank-you in advance. Bill.
Let's table this for now. I did succeed in getting in to LibreOffice's online support. That's the more natural place to try first.
On 12/28/21 12:22, home user wrote:
On 12/28/21 10:30 AM, home user wrote:
Good morning,
I'm not sure if the problem is in LibreOffice or something else. Also, I did try to post this in LibreOffice support, but my login does not work, and trying to create a new account does not work.
(Fedora-34, Gnome, LibreOffice 7.1.8.1, HP LaserJet Pro MFP M180nw) I have a LibreOffice Calc spreadsheet. It has a chart. On my workstation monitor, the chart looks as I desire: border, x and y axes, legend, axis labels, data curves, tick marks along the axes, and a grid in the plot area. When I print the chart to a PDF file and then display the PDF file, it look the same as in LibreOffice Calc. But, when in LibreOffice Calc, I print to the printer, there are no axes and no grid lines. How do I get the axes and grid lines to show?
Thank-you in advance. Bill.
Let's table this for now. I did succeed in getting in to LibreOffice's online support. That's the more natural place to try first. _______________________________________________
Please let the list know what the resolution is. I have encountered this issue as well.
~~R
On 12/28/21 10:30 AM, home user wrote:
Good morning,
I'm not sure if the problem is in LibreOffice or something else. Also, I did try to post this in LibreOffice support, but my login does not work, and trying to create a new account does not work.
(Fedora-34, Gnome, LibreOffice 7.1.8.1, HP LaserJet Pro MFP M180nw) I have a LibreOffice Calc spreadsheet. It has a chart. On my workstation monitor, the chart looks as I desire: border, x and y axes, legend, axis labels, data curves, tick marks along the axes, and a grid in the plot area. When I print the chart to a PDF file and then display the PDF file, it look the same as in LibreOffice Calc. But, when in LibreOffice Calc, I print to the printer, there are no axes and no grid lines. How do I get the axes and grid lines to show?
Thank-you in advance. Bill.
It's solved. See here:
"https://ask.libreoffice.org/t/calc-chart-printout-missing-axes-and-gridlines..."
for the solution.
On Tue, 28 Dec 2021 at 20:07, home user mattisonw@comcast.net wrote:
On 12/28/21 10:30 AM, home user wrote:
Good morning,
I'm not sure if the problem is in LibreOffice or something else. Also, I did try to post this in LibreOffice support, but my login does not work, and trying to create a new account does not work.
(Fedora-34, Gnome, LibreOffice 7.1.8.1, HP LaserJet Pro MFP M180nw) I have a LibreOffice Calc spreadsheet. It has a chart. On my workstation monitor, the chart looks as I desire: border, x and y axes, legend, axis labels, data curves, tick marks along the axes, and a grid in the plot area. When I print the chart to a PDF file and then display the PDF file, it look the same as in LibreOffice Calc. But, when in LibreOffice Calc, I print to the printer, there are no axes and no grid lines. How do I get the axes and grid lines to show?
Thank-you in advance. Bill.
It's solved. See here:
" https://ask.libreoffice.org/t/calc-chart-printout-missing-axes-and-gridlines... "
for the solution.
Zero-width lines in PostScript and PDF have always been problematic. In typography there is a "hairline", and zero-width was generally interpreted as the narrowest line the device could render, e.g., a hairline. Some devices did not do well -- there would be dropouts and rasterization artifacts on curves and sloping lines. I recall one scientific chart created by some specialized commercial package. I told the author it would not reproduce well in the journal. The author came back with the journal and was very pleased with the quality. Turned out the journal's Illustrator expert had printed the illustration, scanned it, and redrew it for publication.
On 12/29/21 4:03 AM, George N. White III wrote:
Zero-width lines in PostScript and PDF have always been problematic. In typography there is a "hairline", and zero-width was generally interpreted as the narrowest line the device could render, e.g., a hairline. Some devices did not do well -- there would be dropouts and rasterization artifacts on curves and sloping lines. I recall one scientific chart created by some specialized commercial package. I told the author it would not reproduce well in the journal. The author came back with the journal and was very pleased with the quality. Turned out the journal's Illustrator expert had printed the illustration, scanned it, and redrew it for publication.
-- George N. White III
That's interesting.
It seems that LibreOffice and other relevant applications and tools need to distinguish between guide lines (used to help the user position and align objects, but not show up in print) and lines that are meant to show up in print (graph axes, tick marks, and background grid lines). Until yesterday, when I saw Tibor's posts in the "Ask LibreOffice" thread, I did not know about "zero width" objects. I do find "zero width" somewhat confusing.
On 12/28/21 4:03 PM, Richard England wrote:
Please let the list know what the resolution is. I have encountered this issue as well.
Richard: Did Tibor's suggestions in the "Ask LibreOffice" thread solve your problem?
Bill.
On Wed, 29 Dec 2021 at 12:47, home user mattisonw@comcast.net wrote:
On 12/29/21 4:03 AM, George N. White III wrote:
Zero-width lines in PostScript and PDF have always been problematic. In typography there is a "hairline", and zero-width was generally interpreted as the narrowest line the device could render, e.g., a hairline. Some devices did not do well -- there would be dropouts and rasterization artifacts on curves and sloping lines. I recall one scientific chart created by some specialized commercial package. I told the author it would not reproduce well in the journal. The author came back with the journal and was very pleased with the quality. Turned out the journal's Illustrator expert had printed the illustration, scanned it, and redrew it for publication.
-- George N. White III
That's interesting.
It seems that LibreOffice and other relevant applications and tools need to distinguish between guide lines (used to help the user position and align objects, but not show up in print) and lines that are meant to show up in print (graph axes, tick marks, and background grid lines). Until yesterday, when I saw Tibor's posts in the "Ask LibreOffice" thread, I did not know about "zero width" objects. I do find "zero width" somewhat confusing
Quoting the Postscript Reference Manual, 2nd Ed. (1995 13th Printing!) p 508:
setlinewidth:
A line width of zero is acceptable: It is interpreted as the thinnest line that can be rendered at device resolution -- in other words, one device pixel wide. Some devices cannot reproduce one-pixel lines, and on high-resolution devices, such lines are nearly invisible. Since the results of rendering such "zero-width" lines are device dependent, their use is not recommended.
My own experience: for many devices, the appearance of a specific pixel depends on what is around it. On a crt, colors are generally generated by some mix of RG and B pixels which may be rectangular. In print, colors are often generated using half-tone methods. The appearance of a one-pixel width line will vary with color choice.
On 12/29/21 10:37 AM, George N. White III wrote:
Quoting the Postscript Reference Manual, 2nd Ed. (1995 13th Printing!) p 508:
setlinewidth:
A line width of zero is acceptable: It is interpreted as the thinnest line that can be rendered at device resolution -- in other words, one device pixel wide. Some devices cannot reproduce one-pixel lines, and on high-resolution devices, such lines are nearly invisible. Since the results of rendering such "zero-width" lines are device dependent, their use is not recommended.
I wonder how many people don't even know about them, and use them without knowing it, as was the case for me.
My own experience: for many devices, the appearance of a specific pixel depends on what is around it. On a crt, colors are generally generated by some mix of RG and B pixels which may be rectangular. In print, colors are often generated using half-tone methods. The appearance of a one-pixel width line will vary with color choice.
Color perception is complex and tricky. I'm a long-time collector of fluorescent minerals. My collection is big. Color perception is important in this hobby. A book(*) that I read many years ago talked about color perception. I remember context (my term) being a part of that. Time also matters. Most monitors are sRGB, which covers less than 50% of the range of colors people can see. I've longed for much better color gamuts for monitors for a long time. No real chance until there are ~550nm to ~400(?)nm and ~700(?)nm to ~550nm tunable lasers that can switch both brightness and wavelength 50+ times per second, and are less than ~50 micrometers across. (I'd hate to see the price of that monitor!) I don't know what it would take to make an almost full color gamut printer. * "The Collector's Book of Fluorescent Minerals" by Manuel Robbins.
On Wed, 2021-12-29 at 12:19 -0700, home user wrote:
I wonder how many people don't even know about them, and use them without knowing it, as was the case for me.
To me, the idea of a zero-width line would mean non-printing, so I would avoid it. In fact, when I print tables and charts, one of the things I experiment with is quite thin lines and not 100% black, as they tend to make tables ugly and more cluttered.
Color perception is complex and tricky. I'm a long-time collector of fluorescent minerals. My collection is big. Color perception is important in this hobby. A book(*) that I read many years ago talked about color perception. I remember context (my term) being a part of that. Time also matters. Most monitors are sRGB, which covers less than 50% of the range of colors people can see. I've longed for much better color gamuts for monitors for a long time.
Perception certainly is a huge part of it. What you view adjacent to an object affects how you perceive it. e.g. The old butcher's trick of putting green plastic around their meat display to make it look redder.
Most monitors (and various video systems) have a very limited gamut, they rely on contrasts between things to avoid looking dull. Cameras do the same thing, and often deliberately emphasise contrasting colours to try and make things pop out at you. You can see that with news bulletins where they've done night filming, and there'll be a black halo around deep blue lighting (where the system has overcompensated).
When it comes to monitors, the actual tint (or hue) of the red phosphor isn't pure red. Not only isn't it 100% saturated red, but it's often not red (on most old domestic CRT TVs it actually verged towards orange). Likewise, with the blue and green phosphors not being 100% mono-chromatic, and not being precisely the same tint on each screen. Apart from meaning you couldn't get pure, or accurate colours, it meant each screen looked different. You get similar impreciseness whether it's CRT, plasma, or LCD.
Also, there's a limit to the range between the dimmest visible emissions and the brightest possible ones. There's a technical limit to how much they can emit, as well as compete with ambient lighting, and as to how much you want to see. e.g. You don't want super bright emissions when viewing TV in a dark room, it hurts your eyes.
One of the tricks employed by TV/monitor manufacturers to say they've improved their colour gamut is to have increased the possible emission brightness further (therefore increased the range of possible colours). Yet, you can rarely use that full range, the super bright is too bright. And many things are filmed to use the full contrast range no matter what the scene is. It only tends to be the arty directors that shoot for more realistic look: A bright sunny day gets a full-contrast picture, indoors gets less contrast. Where you could have set up your wide-range display to show both nicely.
Translate that back to computer displays: When typing black text on white background (representing what you'll eventually print on paper). You don't want 100% burning bright white background simulating your paper background, on a super-bright emitting screen. But that's how most things are usually set up. Then, when you look at a photo on the same set-up, it looks oddly too dim (because it is, comparatively speaking). Word processors ought to let you display a non-100% white typing background, one that the printer isn't going to try and print.
On 12/29/21 8:03 PM, Tim via users wrote:
To me, the idea of a zero-width line would mean non-printing, so I would avoid it. In fact, when I print tables and charts, one of the things I experiment with is quite thin lines and not 100% black, as they tend to make tables ugly and more cluttered.
I agree. Even with 0.02-inch thickness and 170-170-170 (light gray) color, the grid lines come on too strong. I'll get around to trying 0.01 inch one of these days, and if that's still too much or LibreOffice doesn't allow it, a yet lighter gray.
Color perception is complex and tricky....[snip]...I've longed for much better color gamuts for monitors for a long time.
Perception [... snip...] When it comes to monitors, the actual tint (or hue) of the red phosphor isn't pure red. Not only isn't it 100% saturated red, but it's often not red (on most old domestic CRT TVs it actually verged towards orange). Likewise, with the blue and green phosphors not being 100% mono-chromatic, and not being precisely the same tint on each screen. Apart from meaning you couldn't get pure, or accurate colours, it meant each screen looked different. You get similar impreciseness whether it's CRT, plasma, or LCD.
Monitors generally handle white to intermediate saturation very well. It's high saturation that they can't handle, especially in the green to cyan range and the red to violet/purple range. I've known for many years that 255-000-000 is orange-red, not red. What I've most been wanting is an excellent high saturation true red, and high saturation purples and violets. Mixing a little blue into "red", say 255-000-015 makes for a good red (not orange-red) hue, but the result noticeable lacks saturation.
I'm actually quite impressed with how well our visual system adapts (within limits) to the weaknesses of both monitors and printouts.
I agree. Even with 0.02-inch thickness and 170-170-170 (light gray) color, the grid lines come on too strong. I'll get around to trying 0.01 inch one of these days, and if that's still too much or LibreOffice doesn't allow it, a yet lighter gray.
This past Thursday (02/03/2022), I I finally got around to trying to adjust the grid lines down to a thickness of 0.01 inch, and the color to light gray (decimal RGB = (191,191,191)). The resulting printed graph is excellent.
users@lists.stg.fedoraproject.org