Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maybe make inkscapearea=page the default? #37

Open
schtandard opened this issue Dec 16, 2020 · 5 comments
Open

Maybe make inkscapearea=page the default? #37

schtandard opened this issue Dec 16, 2020 · 5 comments
Assignees
Labels
Milestone

Comments

@schtandard
Copy link

schtandard commented Dec 16, 2020

It has always confused me that the default for inkscapearea is drawing and not page. To me, page is the obvious choice. To my knowledge, all other contexts in which svgs are used (e.g. websites) use the page as the bounding box for the drawing. That is to say, users will likely expect that behavior. After all, that's its whole purpose. Using drawing means discarding information on how the drawing should be displayed that was provided by its creator. The aliases crop and nocrop illustrate this quite well: I find it pretty weird for an image inclusion mechanism to crop the image by default.

Especially in the context of LaTeX, I often need to make use of the page boundaries. An example is when I have multiple drawings that should be displayed next to / above each other. Then I can create svgs with identical sizes (or at least aspect ratios) without worrying about the precise drawing size and just scale them identically in LaTeX.

It gets even messier when LaTeX code is involved. As an example, consider the following drawing.
image
Including this with the drawing option cannot yield anything sensible. The page option preserves the intention of the creator (frame added in LaTeX):
image

All in all, this seems like a really strange default choice to me and I would argue for changing it. It isn't a super pressing issue (there are two questions caused by it on tex.sx for now) but I think page would be a much better default.

I do realize, of course, that this would mean breaking backward compatibility, which is unfortunate. If other things doing that are also in the works, I would love to see this change included in the next major release, though.


Files used for illustration:

  • geometric_series.svg
    <?xml version="1.0" encoding="UTF-8"?>
    <svg width="108.49mm" height="12.396mm" version="1.1" viewBox="0 0 108.49 12.396" xmlns="http://www.w3.org/2000/svg">
      <defs>
        <marker id="StopL" overflow="visible" orient="auto">
          <path transform="scale(.8)" d="m0 5.65v-11.3" fill="none" stroke="#000" stroke-width="1pt"/>
        </marker>
      </defs>
      <g transform="translate(-33.067 -30.844)">
        <text x="121.70834" y="37.041664" font-family="'Libertinus Sans'" font-size="4.2333px" letter-spacing="0px" stroke-width=".26458" word-spacing="0px" style="line-height:1.25" xml:space="preserve"><tspan x="121.70834" y="37.041664" stroke-width=".26458">\raisebox{-.5ex}{\(\displaystyle\sum_{k = 0}^\infty \frac{1}{2^k} = 2\)}</tspan></text>
        <path d="m58.208 37.042h29.104 14.552 7.276 3.638 1.819 0.90951 0.45475 0.22737 0.22738" fill="none" marker-end="url(#StopL)" marker-mid="url(#StopL)" marker-start="url(#StopL)" stroke="#000" stroke-width=".265"/>
        <text x="52.916668" y="37.041664" font-family="'Libertinus Sans'" font-size="4.2333px" letter-spacing="0px" stroke-width=".26458" text-align="end" text-anchor="end" word-spacing="0px" style="line-height:1.25" xml:space="preserve"><tspan x="52.916668" y="37.041664" stroke-width=".26458" text-align="end" text-anchor="end">\raisebox{-.5ex}{a series:}</tspan></text>
      </g>
    </svg>
  • svg_test.tex
    \documentclass{article}
    
    \usepackage[inkscapearea=page]{svg}
    
    \begin{document}
    
    \fbox{%
      \includesvg{geometric_series}%
    }
    
    \end{document}
@mrpiggi mrpiggi self-assigned this Dec 17, 2020
@mrpiggi mrpiggi added the bug label Dec 17, 2020
@mrpiggi mrpiggi added this to the v2.03 milestone Dec 17, 2020
@mrpiggi
Copy link
Owner

mrpiggi commented Jan 9, 2021

I will think about it. I also wanted to point out that the desired default behaviour can be achieved very easily by running \svgsetup{inkscapearea=page} after loading the package.

@schtandard
Copy link
Author

For completeness: another question over at tex.sx.

@schtandard
Copy link
Author

Just saw another one.

@mrpiggi
Copy link
Owner

mrpiggi commented Mar 18, 2024

Well, this default setting was probably a bad design decision. I actually can't remember, if this was already in the package, when I took over the maintenance or if it was an imprudent choice by myself.

Nevertheless, as it is now out there like it is quite a long time, I won't change it as this could break a lot of existing documents. But once I find some time, I will place at least a highlighted note at the beginning of the documentation.

@schtandard
Copy link
Author

I understand. Backward compatibility is one of LaTeX's great strengths, though this dogma has been softened quite a bit in recent years (and rightfully so). In this particular case I would argue that the change is worth the trouble, as the vast majority of users will want to crop their images only on occasion and not by default. Ideally, this would be combined with other breaking changes, but I'm not aware of any that are planned / that would be useful. I won't argue it beyond this post, but one possible way of softening the transition would be a deprecation cycle like

  1. For 1 year, issue a warning when the package is loaded without inkscapearea being explicitly set, announcing the planned change and recommending explicitly setting it.
  2. Change the default.
  3. For 1 year, issue a warning when the package is loaded without inkscapearea being explicitly set, mentioning the change and reminding users to explicitly set it to crop their images (or to get rid of the warning).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants