[Octave-bug-tracker] [bug #58704] png plot does nor respect dpi and produces unreadable results

[Ich selber]

URL:
  <https://savannah.gnu.org/bugs/?58704>

                 Summary: png plot does nor respect dpi and produces
unreadable results
                 Project: GNU Octave
            Submitted by: octavian
            Submitted on: Sat 04 Jul 2020 12:37:01 PM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Regression
                  Status: None
             Assigned to: None
         Originator Name: Octavian
        Originator Email: 
             Open/Closed: Open
                 Release: 5.2.0
         Discussion Lock: Any
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

As descriped in bug #55907, the scaling in png files does not work correctly.
Especially font size does not work. Lines are not drawn in the right way, look
at the edges!
On Screen the font size scaling is also terrible. 

Please have a look at the attached files. One is done with dpi 150, one with
dpi 1200, one tried the normal Parameter and one is a screen shot. 
The screenshot font is too small and unreadable.
The dpi 1200 variant shows best the error with the lines.
All png shows problems with the legend at all.


print -dpng "-S2400,1800" -r1200 MyPlot_BugReport.png 
set (gcf, "paperunits", "inches", "paperposition", [0, 0, 4, 3]);
print -dpng -r150 MyPlot150_BugReport.png 
print -dpng -r1200 MyPlot1200_BugReport.png 


That's the way I do. The first line I wrote in the first bug report. I try to
shorten the answer to it: 
The "-r" and "-S" options are for different things.  The "-r" option sets the
resolution (DPI).  It does not set the size of the figure.  If you want a
particular output size, use the paperXXX properties.  See Matlab documentation
(https://www.mathworks.com/help/matlab/ref/print.html) for which Octave has to
maintain compatibility.
The "-S" option is for setting the size of the output in pixels.  Normally,
the number of pixels would be determined automatically by Octave as 
number of pixels = physical_size (in inches) * DPI
But by using the "-S" option you have explicitly said how many pixels you want
and the resolution is irrelevant.  
AND that's the point I disagree: Because there is a need of having size in
pixels AND the resolution in dots per inche (dpi) for solving the fontsize and
the distances which messured in logical font size. This logical font size must
be resolved to pixel and this only can work if I know how many pixels are one
inch. If I use the option S I only overwrite the automatic calculation and now
the physical_size can be calculated for the two parameters S and r.

Sorry to say so, the attached png pictures show that distance and font size
resolving does not work.

! I'm sorry to say so, it is very urgent and important for me to get good
looking drawings for printing purpose !
The prefereed format would be emf, does not work at all. ESP does not work
because of character support and png does not work of layout.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Sat 04 Jul 2020 12:37:01 PM UTC  Name: MyPlot150_BugReport.png  Size:
60KiB   By: octavian

<http://savannah.gnu.org/bugs/download.php?file_id=49425>
-------------------------------------------------------
Date: Sat 04 Jul 2020 12:37:01 PM UTC  Name: MyPlot1200_BugReport.png  Size:
614KiB   By: octavian

<http://savannah.gnu.org/bugs/download.php?file_id=49426>
-------------------------------------------------------
Date: Sat 04 Jul 2020 12:37:01 PM UTC  Name: MyPlot_BugReport.png  Size:
241KiB   By: octavian

<http://savannah.gnu.org/bugs/download.php?file_id=49427>
-------------------------------------------------------
Date: Sat 04 Jul 2020 12:37:01 PM UTC  Name: MyPlot_BugReport_ScreenShot.png 
Size: 347KiB   By: octavian

<http://savannah.gnu.org/bugs/download.php?file_id=49428>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?58704>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/