From: Jim D. <ji...@di...> - 2015-03-04 07:42:13
|
I have gotten things to the point where the differences are due to round off error, the rendering of non-solid lines, and plot symbols generated by commands that utilize plhrsh (i.e. plsym, plpoin, and plpoin3). Rendering non-solid lines I can't think of a simple solution to this problem without a major change. As it currently stands, the end user would need to look very closely to see any differences. It really is a problem if you comparing output files. Plot Symbol Issue With the current architecture, I can either store them as a text string (if there is a unicode representation) or as rendered vectors. However, if they are stored as a text string, there is no way to distinguish points from the other strings. Some drivers, like ps, set dev_hrshsym to true, which forces the symbols to be rendered as vectors (perhaps they don't have the hershey font). When rendering a metafile on such a device the plot symbols might not get rendered correctly (or at all). Options 1) Let the plot symbols get rendered as vectors Pros: Plot metafiles will always work regardless of the output device Cons: For devices that have dev_hrshsym = 0, a rendered metafile will be different 2) Let the plot symbols be represented as text strings Pros: Better quality output on devices that have dev_hrshym = 0 Cons: For devices that have dev_hrshsym = 1 (gcw, pdf, ps, psttf, wxwidgets_dev), a metafile might not render correctly 3) Represent plot symbols as a different operation in the metafile Pros: Will work correctly regardless of the dev_hrshsym setting Cons: Some changes to plsym are required Incidentally, I discovered some issues in the unicode encoding in plP_text that was doubly rendering strings on the cairo device and I have fixed that issue. Also, I believe I have identified the resizing issue on the xcairo device and I can generate a fix for that problem (if my hypothesis is correct). |