Hi, In org-display-inline-image--width we have the restriction that percentages and floating point width specifications must be between 0 and 200% (or 0.0 and 2.0) of the text area. Reading the comments, it sounds like this is done because you might specify something like 1.2\linewidth, but you wouldn't write something like 5.0\linewidth. I guess that's fair, but I can't say with certainty that there is never any valid reason to, e.g., specify that you want a width of 500% of the text area. I'm also not sure that we should prevent people from using 5.0\linewidth, even if it is a bit odd. The intent is clear. Maybe I'm missing a reason as to why this is done? Best Matt
[-- Attachment #1: Type: text/plain, Size: 548 bytes --] Hi Matt, > I’m also not sure that we should prevent people from using > 5.0, even if it is a bit odd. The intent is clear. > > Maybe I’m missing a reason as to why this is done? Just to be clear, this isn’t preventing people from setting image widths to say `5.0\linewidth', it just prevents them from being previewed at 5x the buffer text width as that seems a bit ridiculous. Happy to reconsider the [0,2] preview restriction, but I don’t think ridiculously large in-buffer images make much sense. All the best, Timothy
Timothy <tecosaur@gmail.com> writes:
> Just to be clear, this isn’t preventing people from setting image widths to say
> `5.0\linewidth', it just prevents them from being previewed at 5x the buffer text
> width as that seems a bit ridiculous. Happy to reconsider the [0,2] preview
> restriction, but I don’t think ridiculously large in-buffer images make much
> sense.
Thanks for the response Timothy.
I agree that requesting an image to be >2x the buffer text width is a
strange request, and it's not one I've ever tried to give. But, I think
the salient point is that it's a very clear request, and I think org
should carry it out. I'm all in favor of org helping people not shoot
themselves in the foot, but I don't think it should prevent people from
doing so, especially when they're clear about their intentions. I also
think this qualifies as a case where someone /might/ have a valid reason
for doing this.
I guess we could make the upper limit customizable and default to
2.0. But, this is a bit confusing because it doesn't apply to the
original image width. I also think adding too many customizable
variables adds to complexity. I don't know. Thoughts? This also isn't a
feature I've ever needed... so I'm happy to concede and revisit it in
the future if I have a valid use case for it.
Matt
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --] Hi Matt, > I agree that requesting an image to be >2x the buffer text width is a > strange request, and it’s not one I’ve ever tried to give. But, I think > the salient point is that it’s a very clear request, and I think org > should carry it out. I’m all in favor of org helping people not shoot > themselves in the foot, but I don’t think it should prevent people from > doing so, especially when they’re clear about their intentions. I also > think this qualifies as a case where someone /might/ have a valid reason > for doing this. It occurred to me that large values would only really appear when occurring in a narrower scope, e.g. in a multi-column document an image which is multiple columns wide. Say, ┌──── │ #+attr_latex: 3.0\columnwidth └──── However, I doubt that when previewing the image in Org one would want the preview to be 3x the buffer text area width! I suppose the exception would be say something like ┌──── │ #+attr_org: :width 300% └──── Though I can’t imagine why you’d want that… I think you don’t raise an unreasonable point, however I’m tempted to let this sit till we hear from someone who actually runs into this as an issue. All the best, Timothy
Timothy <tecosaur@gmail.com> writes: > It occurred to me that large values would only really appear when occurring in a > narrower scope, e.g. in a multi-column document an image which is multiple > columns wide. Say, > ┌──── > │ #+attr_latex: 3.0\columnwidth > └──── > > However, I doubt that when previewing the image in Org one would want the > preview to be 3x the buffer text area width! Good point. I could see someone using this as an argument against interpreting :width 3.0\columnwidth as :width 3.0, but I do see the value in interpreting :width 0.8\linewidth as :width 0.8, so I don't know. > I suppose the exception would be say something like > ┌──── > │ #+attr_org: :width 300% > └──── > Though I can’t imagine why you’d want that… > > I think you don’t raise an unreasonable point, however I’m tempted to let this > sit till we hear from someone who actually runs into this as an issue. Yeah I think that makes sense. Thanks for considering this anyway! Matt
Matt Huszagh <huszaghmatt@gmail.com> writes: > I agree that requesting an image to be >2x the buffer text width is a > strange request, and it's not one I've ever tried to give. But, I think > the salient point is that it's a very clear request, and I think org > should carry it out. I'm all in favor of org helping people not shoot > themselves in the foot, but I don't think it should prevent people from > doing so, especially when they're clear about their intentions. I also > think this qualifies as a case where someone /might/ have a valid reason > for doing this. +1M. We need to ensure org does not become too opinionated regarding what is reasonable. If there is no good reason to impose an upper limit, we should avoid doing so. Org is so powerful and open to customisation, it is unlikely any of us can foresee all possible scenarios, so we need to be careful not to artificially constrain the possibilities. , > > I guess we could make the upper limit customizable and default to > 2.0. But, this is a bit confusing because it doesn't apply to the > original image width. I also think adding too many customizable > variables adds to complexity. I don't know. Thoughts? This also isn't a > feature I've ever needed... so I'm happy to concede and revisit it in > the future if I have a valid use case for it. > +1M. Org already has an excessive number of custom settings. We need to actively avoid adding mor whenever we can. At first glance, a custom variable seems to be a good option. However, once you take testing and maintenance into consideration and think about the basic testing principal of ensuring all possible paths are tested, you soon see why adding such custom options really increases maintenance overhead. If there is a legitimate technical reason to set an upper limit, then that is fine. However, setting a limit because you cannot imagine anyone wanting to go above it is probably not.
Hi, If org mode won't blow up, kick out the restriction. It is not up to us to decide what users will have use for or not. Besides, if someone specifies an outrageously wide picture by mistake, it's a mistake which is easy to spot and fix. I finish my argument with a small war story. Many years ago my colleagues and I tried to create a computational grid around a ship, for flow simulations. However, the grid generation program refused to follow our instructions, no matter what we tried. We reported this to the company behind the grid generation software, and it turned out they had imposed a 1000 m size limit on grids. It just so happens that many merchant ships are almost 400 m long, and when you extend the computational grid sufficiently up- and downstream, you get a grid well over 1000 m long. Given the magnitude limit for double precision floating point numbers, 1000 m was a ridiculous limit. yours Rasmus