Fix for EPS export area (trunk, 0.91.x)

[su_v]

Current trunk and 0.91.x builds use the PS settings for EPS export (even though the export dialog loads and saves the EPS settings). With new prefs (no export settings for PS), EPS export always exports the page area (using a tight bbox around the page content).

Steps to reproduce:
1) reset Inkscape prefs (rename the current preferences.xml)
2) download attached test case, and run these commands (cli export):

$ inkscape -V
Inkscape 0.91pre3 r13696 (Jan 14 2015)
$ inkscape -f test1.svg -E test1.eps
$ inkscape -f test1.svg -C -E test1-C.eps
$ inkscape -f test1.svg -D -E test1-D.eps
$ grep '%%BoundingBox' test1*.eps
test1-C.eps:%%BoundingBox: 181 333 375 520
test1-D.eps:%%BoundingBox: 181 333 375 520
test1.eps:%%BoundingBox: 181 333 375 520
$
$ inkscape -f test1.svg -P test1.ps
$ inkscape -f test1.svg -C -P test1-C.ps
$ inkscape -f test1.svg -D -P test1-D.ps
$ grep '%%PageBoundingBox' test1*.ps
test1-C.ps:%%PageBoundingBox: 181 333 375 520
test1-D.ps:%%PageBoundingBox: 0 -1 1062 185
test1.ps:%%PageBoundingBox: 181 333 375 520

3) launch inkscape, open test case and export to PS
   (default setting i.e. page area)
4) quit inkscape, repeat step 2
--> same result

5) launch inkscape, open test case and export to PS
   (use 'objects size' aka drawing area)
6) quit inkscape, repeat step 2
--> now all EPS exports use drawing area (from the PS export setting)

Same can be reproduced via GUI: EPS export uses PS export area,
even though the export dialog loads and saves the settings separately.

Reproduced on OS X 10.7.5 with Inkscape 0.91pre3 r13696 and 0.91+devel r13850.
AFAICT this is a regression related to the commits for bug #499965.

Attached patch tested successfully on OS X 10.7.5 with 0.91pre3 r13696 and 0.91+devel r13850

[jazzynico (jazzynico)]

Tested on Windows XP, Inkscape trunk revision 13851.
The patch looks good, but I have had an unexpected result (very probably unrelated to your patch) the first time I exported to EPS. The BB was different that the one from the PS export, but incorrect.
I'll try again later on Crunchbang Waldorf to be sure.

[su_v (suv-lp)]

On 2015-01-15 18:32 (+0100), jazzynico wrote:
> The patch looks good, but I have had an unexpected result (very
> probably unrelated to your patch) the first time I exported to EPS.

On the command line? AFAIU on the command line, EPS has a different default when exporting without '-C' or '-D' than PS: it exports by default the drawing content (as encapsulated file format, this makes sense), whereas PS defaults to the page content if not specified otherwise.

[su_v (suv-lp)]

On 2015-01-15 18:32 (+0100), jazzynico wrote:
> The patch looks good, but I have had an unexpected result (very
> probably unrelated to your patch) the first time I exported to EPS.

… and IIRC I noticed some incorrect bboxes in EPS files with older cairo versions (would have to re-investigate). Local tests as described earlier have been done with cairo 1.14.0.

[jazzynico (jazzynico)]

> On the command line?

No, with the GUI.

> Local tests as described earlier have been done with cairo 1.14.0.

Tests on Windows are still done with cairo 1.11.2...
Fixing the rulers performance issues would allow us to jump to a much more recent version!

[su_v (suv-lp)]

On 2015-01-15 18:47 (+0100), ~suv wrote:
> … and IIRC I noticed some incorrect bboxes in EPS files with older
> cairo versions

I remembered incorrectly: seems not related to cairo versions and the bug reported here - AFAICT grouping the drawing content first (Ctrl+A, Ctrl+G, Shift+Ctrl+O to copy the id), and exporting the group by id (using "object's size") produces PostScript files with wrong (or odd) bbox, independent of cairo version, patch, PS or EPS. Tested with r13852 (patched and unpatched).

[su_v (suv-lp)]

Attaching revised version of proposed patch (tested with trunk 0.91+devel r13854 only), please review:

AFAICT the regression reported here started with r11654 where the values for the new optiongroup parameters are taken from 'ext' instead of 'mod' (same happened earlier for bleed with PS/EPS (r12345)). Since 'ext' currently checks PS output in both cases (SP_MODULE_KEY_PRINT_CAIRO_PS), the same parameter data is used for the export area in either format (?).

The second version of the patch switches 'ext' to 'mod' as source for the parameters to get for new_areaPage and bleedmargin_px (like for the rest of the parameters), in addition to changing the output extension to SP_MODULE_KEY_PRINT_CAIRO_EPS in CairoEpsOutput::save(). I don't really know whether this is correct ...

--
Note: r11654 introduced the same mix of 'mod' and 'ext' for PDF output (AFAICT it doesn't have side-effects there because there is only one output format).

[su_v (suv-lp)]

On 2015-01-15 20:13 (+0100), ~suv wrote:
> (…) grouping the drawing content first (Ctrl+A, Ctrl+G, Shift+Ctrl+O
> to copy the id), and exporting the group by id (using "object's
> size") produces PostScript files with wrong (or odd) bbox, (…)

Reported as
Bug #1411718 “Export to PS/EPS/PDF of 'object' per id ignores viewBox”

[jazzynico (jazzynico)]

Patch v2 tested successfully on Crunchbang Waldorf, with Inkscape trunk 13860 (using Evince as EPS/PS viewer, due to a bug in Ghostview). Patch v1 also works, but v2 is more consistent with the way the extension preferences are handled in the code.

[su_v (suv-lp)]

Thx for testing and review - patch v2 committed to trunk in rev 13863.

[su_v (suv-lp)]

@ScislaC - could you please review and approve backporting r13863 from trunk <lp:inkscape> to the stable release branch <lp:inkscape/0.91.x>?

[ScislaC (scislac)]

Committed as r13717 in 0.91.x.