octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #58001] All points in plot sent to output resu


From: Nicholas Jankowski
Subject: [Octave-bug-tracker] [bug #58001] All points in plot sent to output resulting in very large files
Date: Sun, 20 Sep 2020 11:01:08 -0400 (EDT)
User-agent: Mozilla/5.0 (Linux; Android 9; moto g(6)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.101 Mobile Safari/537.36

Follow-up Comment #3, bug #58001 (project octave):

I agree this should be a won't fix, at least for default behavior. But it is a
nice wish list item for a plot option or maybe separate function to
"intelligently" dedensify plot data.  is there an existing routine out there
that could do this?  Something that would check for e.g, data on a line to a
"won't move any pixels" degree, and trim those out, etc.  It would be hard
without an integrated plot routine like MATLAB has, where the routines could
"talk" to know what target pixel size was based on the print details. But
maybe if you're calling the function its enough to just specify a desired
resolution.

Background-
I ran into a similar thing very recently when putting a figure heavy document
based on data in MS Excel (yes I know). The data was generated in SPICE for a
nonlinear circuit, and was set to save all data points (that software seems
has default plot data compression that meets the "intelligent" description
above, butit was off for generating this data and it's not open software).  At
startup and nonlinear transitions the 30s long simulation would have a couple
thousand points at ~1e-7s time steps.  I usually export excel plots as EMF
vector graphics to avoid pixellation, but excel keeps the full dataset,
including data outside the plot range. Even compressed each figure was adding
a couple MB to the MS Word filesize.  The plot scale was large enough and most
regions smooth enough that an intelligently chosen 1-200 points would likely
have been indistinguishable.  BUT a blind uniform spacing would have lost
shape in key areas. After the easy manual data trimming, which still took
forever, I'm currently working with a 60MB word doc that if all pics were
replaced with PNG would probably be <5MB guessing by the sizes in the docx
container.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]