Size image by area
Clash Royale CLAN TAG#URR8PPP
up vote
10
down vote
favorite
Sometimes I have to insert many relatively small different images, with different aspect ratio, which widths must be adjusted one by one in order to look approximately of the same size.
In such cases it would be useful to be able to size the image by area, that is choose the area and let LaTeX set image width or height so that width x height = area (keeping aspect ratio).
The ideal would be a new command built upon includegraphics
able to accept an area
parameter (square root of area would be even better, because in order to get a sense of the size of the area you usually end up in calculating its square root). Such a command, given for example two images img_a
(having aspect ratio W:H=2:1) and img_b
(having aspect ratio W:H=2:3), with the following code
includegraphicsbyarea[area=18]img_a % suppose area in square centimeters
includegraphicsbyarea[area=18]img_b
includegraphicsbyarea[area=32]img_a
would insert:
img_a
with width of 6 cm and height of 3 cm (6x3=18, 6:3=2:1)img_b
with width of 3.464 cm and height of 5.196 cm (3.464x5.196=18, 3.464:5.196=2:3)img_a
with width of 8 cm and height of 4 cm (8x4=32, 8:4=2:1)
Would it be possible?
Thanks in advance for any clue.
graphics
add a comment |Â
up vote
10
down vote
favorite
Sometimes I have to insert many relatively small different images, with different aspect ratio, which widths must be adjusted one by one in order to look approximately of the same size.
In such cases it would be useful to be able to size the image by area, that is choose the area and let LaTeX set image width or height so that width x height = area (keeping aspect ratio).
The ideal would be a new command built upon includegraphics
able to accept an area
parameter (square root of area would be even better, because in order to get a sense of the size of the area you usually end up in calculating its square root). Such a command, given for example two images img_a
(having aspect ratio W:H=2:1) and img_b
(having aspect ratio W:H=2:3), with the following code
includegraphicsbyarea[area=18]img_a % suppose area in square centimeters
includegraphicsbyarea[area=18]img_b
includegraphicsbyarea[area=32]img_a
would insert:
img_a
with width of 6 cm and height of 3 cm (6x3=18, 6:3=2:1)img_b
with width of 3.464 cm and height of 5.196 cm (3.464x5.196=18, 3.464:5.196=2:3)img_a
with width of 8 cm and height of 4 cm (8x4=32, 8:4=2:1)
Would it be possible?
Thanks in advance for any clue.
graphics
Do your images have the same area before you include them?
â samcarter
Aug 19 at 11:17
@samcarter No, of course.
â mmj
Aug 19 at 14:14
add a comment |Â
up vote
10
down vote
favorite
up vote
10
down vote
favorite
Sometimes I have to insert many relatively small different images, with different aspect ratio, which widths must be adjusted one by one in order to look approximately of the same size.
In such cases it would be useful to be able to size the image by area, that is choose the area and let LaTeX set image width or height so that width x height = area (keeping aspect ratio).
The ideal would be a new command built upon includegraphics
able to accept an area
parameter (square root of area would be even better, because in order to get a sense of the size of the area you usually end up in calculating its square root). Such a command, given for example two images img_a
(having aspect ratio W:H=2:1) and img_b
(having aspect ratio W:H=2:3), with the following code
includegraphicsbyarea[area=18]img_a % suppose area in square centimeters
includegraphicsbyarea[area=18]img_b
includegraphicsbyarea[area=32]img_a
would insert:
img_a
with width of 6 cm and height of 3 cm (6x3=18, 6:3=2:1)img_b
with width of 3.464 cm and height of 5.196 cm (3.464x5.196=18, 3.464:5.196=2:3)img_a
with width of 8 cm and height of 4 cm (8x4=32, 8:4=2:1)
Would it be possible?
Thanks in advance for any clue.
graphics
Sometimes I have to insert many relatively small different images, with different aspect ratio, which widths must be adjusted one by one in order to look approximately of the same size.
In such cases it would be useful to be able to size the image by area, that is choose the area and let LaTeX set image width or height so that width x height = area (keeping aspect ratio).
The ideal would be a new command built upon includegraphics
able to accept an area
parameter (square root of area would be even better, because in order to get a sense of the size of the area you usually end up in calculating its square root). Such a command, given for example two images img_a
(having aspect ratio W:H=2:1) and img_b
(having aspect ratio W:H=2:3), with the following code
includegraphicsbyarea[area=18]img_a % suppose area in square centimeters
includegraphicsbyarea[area=18]img_b
includegraphicsbyarea[area=32]img_a
would insert:
img_a
with width of 6 cm and height of 3 cm (6x3=18, 6:3=2:1)img_b
with width of 3.464 cm and height of 5.196 cm (3.464x5.196=18, 3.464:5.196=2:3)img_a
with width of 8 cm and height of 4 cm (8x4=32, 8:4=2:1)
Would it be possible?
Thanks in advance for any clue.
graphics
edited Aug 23 at 10:49
asked Aug 19 at 11:08
mmj
687418
687418
Do your images have the same area before you include them?
â samcarter
Aug 19 at 11:17
@samcarter No, of course.
â mmj
Aug 19 at 14:14
add a comment |Â
Do your images have the same area before you include them?
â samcarter
Aug 19 at 11:17
@samcarter No, of course.
â mmj
Aug 19 at 14:14
Do your images have the same area before you include them?
â samcarter
Aug 19 at 11:17
Do your images have the same area before you include them?
â samcarter
Aug 19 at 11:17
@samcarter No, of course.
â mmj
Aug 19 at 14:14
@samcarter No, of course.
â mmj
Aug 19 at 14:14
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
4
down vote
accepted
Here is an approach not redefining includegraphics
. However compared to scale
option, I cut a branch because I don't have details of graphicx.sty
in head, so possibly there would be a way to delegate to driver the final rescaling, which I am losing here. Ping @DavidCarlisle.
(I use xintexpr
but xfp
of course would do it as well as in Joseph's answer; also, up to some more cumbersome notations one could use only the macros of xintfrac
, giving a tiny speed-up as expression parsing is skipped).
documentclassarticle
usepackagegraphicx
usepackagexintexpr
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexxinttheiexpr[5]% round fixed point to 5
% fractional digits
dimexpr#1relax/
sqrt(Gin@nat@height*Gin@nat@width)
relax%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
newboxmybox
Equality only expected up to 5 digits of precision due to intrinsic
limitations of graphicx computations.
setboxmyboxhboxincludegraphics[sqrtofarea=2cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr2cmrelax*dimexpr2cmrelaxrelax (4cm$^2$)
setboxmyboxhboxincludegraphics[sqrtofarea=5cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr5cmrelax*dimexpr5cmrelaxrelax (25cm$^2$)
enddocument
The sentence at bottom of image must be amended: in TeX all dimensions are integer multiples of 1sp. When we set the area square root as key, we automatically limit the achievable precision of the area. For example 5cm
internally in TeX gives 9323399sp, hence a square equal to 86925768913201 as in image above. The previous square is 86925750266404 and the next one is 86925787560000, so they diverge in the 7th digit already and we can never overcome that possible imprecision when comparing a square with a produce height times width. Above we observe discrepancy already in 5th digit so the sentence is probably not completely wrong, but I felt I needed to add this mathematical precision.
Here is same with xfp
(basically copied from Joseph's way of using it):
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexfpeval#1/sqrt(Gin@nat@height*Gin@nat@width)%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
enddocument
About this:
no wrapping of
#1
indimexpr #1relax
needed here;xintexpr
could easily be extended to recognizecm
,in
,pt
, etc ... units so that e.g.2cm
is understood automatically, but the problem is that it would then do an exact conversion to a fractional number ofsp
units, whereas TeX process is more complex than simply using a proportionality factor and proceeds with rounding and truncating in various directions at various stages; so using exact conversion factor means not doing same operations as TeX itself. For this reason, no such units are defined yet inxintexpr
and user must go viadimexpr #1relax
; thexintexpr
parser will applynumber
to this, triggering TeX's own way to convert dimensional units.I am not expert in
xfp
so I don't know if sometimes such computation could result in a scientific notation which would break TeX later; in thexintexpr
solution I applied a transformation to fixed point value with 5 fractional digits. I don't know how one does that inxfp
and whether it could be needed here in some cases. In the MWE above it works fine.
It seems that I wrote too early about "optimal" solutions. Your solution as far as I understand adds thesqrtofarea
option (nice name, by the way) to standardincludegraphics
(which is better than adding a new command). I also tested thesqrtofarea
option together with the standardangle
option ofincludegraphics
ans it works, whereas if I add the sameangle
option when using the commandincludegraphicsbyarea
of other solutions I get an error.
â mmj
Aug 23 at 10:29
I think @DavidCarlisle should be pinged about correct way to add this option toincludegraphics
. Good to hear it works withangle
option. I added some mathematical comment at bottom of answer.
â jfbu
Aug 23 at 10:30
I think thatsqrtofarea
should definitively become a standard option ofincludegraphics
. Scaling by area is the best way of sizing many images different in size and aspect ratio so that they look approximately of the same size.
â mmj
Aug 23 at 10:47
unfortunately even with e-TeX'snumexpr, dimexpr
, it requires some work to avoid arithmetic overflows when implementing computations at low-level. Already graphicx/graphics has some extra code for obtaining ratio of two lengths which works well enough in 99.99% of real life situations, and is cleverly compact, but sqrtofarea requires extra implementation effort as it seems at least square root must be handled. Naturally graphicx will never load package like xint and all its unneeded macros. Perhaps in future it will have xfp automatically, then of course, sqrtofarea becomes feasible.
â jfbu
Aug 23 at 10:55
Maybesqrt(Gin@nat@height)*sqrt(Gin@nat@width)
would help in avoiding overflow? (I barely understand what you mean, sorry if I suggested something stupid).
â mmj
Aug 23 at 11:03
 |Â
show 1 more comment
up vote
8
down vote
Scaling to an area is an unusual request: normally one knows the target height or width. The following takes the image and scales such that the area is that given in the optional argument, interpreted in square centimetres:
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareaareadefGarea@area#1
define@keyGareaareaunitdefGarea@unit#1
define@keyGinarea % So we can pass through easily
define@keyGinareaunit
newcommand*Garea@area
newcommand*Garea@unitcm
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@area@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalsqrt((Garea@area * 1 Garea@unit * 1 Garea@unit)
/(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[area=100]example-image-a
includegraphicsbyarea[area=100,areaunit=pt]example-image-a
enddocument
It still applies any options to the graphic: I've ordered such that the area scale is first, but one might want to put it last.
An alternative interface uses the square root of the area of the image: conveniently this has units we can work with directly
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareasqrtareadefGarea@sqrtarea#1
define@keyGinsqrtarea
newcommand*Garea@sqrtarea
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@diag@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalGarea@sqrtarea /(sqrt(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[sqrtarea = 5cm]example-image-a
includegraphicsbyarea[sqrtarea = 10cm]example-image-a
enddocument
(See the answer by mmj for an alternative name for the key.)
Your answer is clean and works well, but I would like to choose the unit of measure of the area. To obtain that it might be helpful using as parameter the square root of area instead of area. I think that using the square root of area is better, because to get a sense of the area you usually end up calculating the square root (I updated my question to underline that).
â mmj
Aug 20 at 22:05
I've added a follow up with an improved (IMHO) version of your solution. If you agree, please consider replacing your actual solution with that one, and I will delete the follow up, just for clarity towards future readers.
â mmj
Aug 22 at 12:23
@mmj I've added a version using the diagonal as the scaling determinant: that has a square-root relationship to area, and has units, and has a clear name :)
â Joseph Wrightâ¦
Aug 22 at 12:43
1
@mmj You'd be better to post your answer code as an answer, rather than edit it into the question. The site structure works best that way: as it stands, its a bit confusing.
â Joseph Wrightâ¦
Aug 22 at 12:44
Diagonal is a nice name and of course varies linearly with the width and height of an image, but it does not vary linearly when the aspect ratio changes, and the command is supposed to deal with images having different aspect ratios. What you call diagonal is actually the same parameter I used to modify your code, it is the square root of the area. Calling it diagonal is misleading the user because he/she might think that a 16x1 image and a 4x4 image will have the same diagonal, whereas they will have the same area (16) but very different diagonals, about 16 and 5.66 respectively.
â mmj
Aug 22 at 14:29
 |Â
show 6 more comments
up vote
6
down vote
Update 3
This is the last revision, I promise.
The only change is the use of pgfmath.sty
in place of fp-eval.sty
which, in turn, required a little special handling to avoid dimension too large
errors. As well, the use of pgfmath.sty
allowed for considerable simplification. The new output is identical to the old.
%===8><-----%
I was unhappy with the way that I left the scaletoarea macro. It has been altered to be, hopefully, a little more user-friendly. I have made it possible to use the options to includegraphics
for all of the macros. Take a look at the examples.
%===8><---%
I take it that you want all of the graphics to have the same area regardless of the aspect ratio. The following code does that.
There are two approaches outlined here.
The first scales subsequent graphics based on the size of the first graphic Use fpic
for the first graphic; using spic
for the subsequent graphics will size them to have the same area as the first graphic. Use the options to fpic
(the same as those to includegraphics
) to size the first graphic accordingly.
Second, if you know the target area, you can use scaletoarea<unitless area><linear unit of area><name of graphic>
. For example, if you were to scale a graphic, foo
, so that it is 5 square inches in area, you would write: scaletoarea5infoo
. Any of the units recognized by TeX can be used.
documentclassarticle
usepackagegraphicx,calc,pgfmath
usepackage[margin=0.5in]geometry
newlengthfpicw
newlengthfpich
newlengthspicw
newlengthspich
newsaveboxfirstpic
newsaveboxnextpics
newlengthtargetarea
%% fpic[<options to includegraphics>]<name of graphic>
newcommandfpic[2]% First picture, use includegraphics, and options
sboxfirstpicincludegraphics[#1]#2%
settoheightfpichuseboxfirstpic%
settowidthfpicwuseboxfirstpic%
useboxfirstpic%
%% spic[<options to includegraphics>]<graphic name>
newcommandspic[2]% Second and succeeding pictures
sboxnextpicsincludegraphics[#1]#2%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((fpicw/spicw)*(fpich/spich))%
scaleboxscalinguseboxnextpics%
typeout**The scaling (#2) = scaling% Comment-out if not needed
%% scaletoarea[<options to includegraphics>]<unitless area><unit of area (linear)><graphic name>
newcommandscaletoarea[4]%
pgfmathsetmacromytmpsqrt(#2)%
setlengthtargetareamytmp #3%
sboxnextpicsincludegraphics[#1]#4%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
typeout++The scaling (#4) = scaling% Comment-out if not needed
%% scaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
newcommandscaletoareab[3]%
setlengthtargetarea#2%
sboxnextpicsincludegraphics[#1]#3%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
message++The scaling (#3) = numberscaling%
begindocument
fpic[width=1.25in]PeppersspicPastaspicOldImagespicBethanyDrawing
scaletoarea3inPeppersscaletoarea12cmPastascaletoarea2inOldImagescaletoarea61pcBethanyDrawing
scaletoarea[width=0.5in,height=3in,keepaspectratio=false]3inPeppers
scaletoareab[width=0.5in,height=3in,keepaspectratio=false]1.732050807568877inPeppers
enddocument
My math was wrong forscaletoarea
. The first argument toscaletoarea
should be the square root of the desired area. Made the correction in the code listing.
â sgmoye
Aug 19 at 18:45
I have modified my original answer to modify howscaletoarea
works.
â sgmoye
Aug 20 at 11:58
I tested the previous version of yourscaletoarea
command and it worked well, but above all I liked the use of square root of area as parameter instead of area. In fact using the square root of area is better, because to get a sense of the area you have in any case to calculate the square root. And you save a parameter in comparison to the new current version that needs an additional parameter for the unit of measure. Please consider restoring the use of square root of area as parameter forscaletoarea
command.
â mmj
Aug 20 at 21:31
I'm a little tied up now, but I will get to it later today or tomorrow. Thanks.
â sgmoye
Aug 20 at 22:28
@mmj Check now. The macro (last one in the code) isscaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
. Included example and output.
â sgmoye
Aug 21 at 0:41
 |Â
show 1 more comment
up vote
3
down vote
Here is an MCVE that fulfills your requirements provided th. I have also added commented the code and added a full explanation with regards to the logic of the program.
Sample output:
Now the explanation:
The code!:
documentclass[12pt]article
usepackagegraphicx, color
usepackage[margin=0.5in]geometry
usepackagecalculator % Very important package. Provides
% basic mathematical operations like
% addition, subtracting, multiplying
% dividing, rounding, truncating, and
% finding the GCD (greatest common divisor).
usepackagecaption, amsmath, amssymb
makeatletter
newcommand*getlength[1]strip@pt#1
makeatother
% For the area, and ratio (width:height) = (xRatio:yRatio)
newlengthareaGiven
newlengthxRatio
newlengthyRatio
% Accepts 4 argments: area, width ratio, height ratio, and name of image (respectively).
newcommand*adjustImage[4]%
setlengthareaGiven#1 cm
setlengthxRatio#2 cm
setlengthyRatio#3 cm
noindent Given information~~~~~~~~~~~: textbfarea = #1cm,
textbfratio $(width:height) = #2:#3$.
% Convert the unit from pt to cm. Note, 1pt = 0.0352778cm.
% If you really care about exact numbers, 1.0000008pt = 0.035277806cm.
% If inches is the unit to focus on, then change 0.0352778 to 0.0138889.
MULTIPLYgetlengthareaGiven0.0352778areaInCm
MULTIPLYgetlengthxRatio0.0352778xRatioInCm
MULTIPLYgetlengthyRatio0.0352778yRatioInCm
noindent Converting from pt to cm : textbfarea = areaInCm cm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% Keep in mind that there will be rounding errors. The answer
% we will obtain is a decimal answer. Since pixels are atomic, we need to
% truncate (or round) the decimal values to secure a whole number.
% I used the TRUNCATE command, you can comment the next three line and
% uncomment the ROUND commands if you want to round.
TRUNCATE[0]areaInCmareaInCm
TRUNCATE[0]xRatioInCmxRatioInCm
TRUNCATE[0]yRatioInCmyRatioInCm
% OR use round instead. It is better for images with areas 100+.
% ROUND[0]areaInCmareaInCm
% ROUND[0]xRatioInCmxRatioInCm
% ROUND[0]yRatioInCmyRatioInCm
noindent After truncating~~~~~~~~~~~~~: textbfarea = areaInCm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% The following are the steps of find the result mathematically.
% This is explained in details at the end of the docmument.
MULTIPLYxRatioInCmyRatioInCmk % 1) finds (a*b) in ak*bk = area.
DIVIDEareaInCmkk % 2) finds (area/(a*b)) in k^2 = (area/(a*b)).
SQUAREROOTkkFinal % 3) finds of k in k = sqrt((area/(a*b))).
MULTIPLYxRatioInCmkFinalx % 4) multiplies the x-ratio by k.
MULTIPLYyRatioInCmkFinaly % 5) multiplies the y-ratio by k.
noindent textbfFinal dimensions are~~~:
textbfwidth = x cm, textbfheight = y cm.
begincenter
includegraphics[width = x cm, height = y cm]#4 % 6*3 cm
captionoffigure
textbfarea = #1cm, textbfratio
$(width:height) = #2:#3$ $longrightarrow$
textbfwidth = x cm, textbfheight = y cm.
endcenter
begindocument
noindent
textcolorredtextbfExample A:newline
adjustImage1821example-image-a % area = 18cm, ratio (width:height) = 2:1
textcolorredtextbfExample B:newline
adjustImage1823example-image-b % area = 18cm, ratio (width:height) = 2:3
textcolorredtextbfExample C:newline
adjustImage3221example-image-c % area = 32cm, ratio (width:height) = 2:1
% Maximum area is 575 units!
% adjustImage57521TestImage.png % area = 575cm, ratio (width:height) = 2:1
newpage
newgeometrymargin=1in
% Here is the explanation of the logic.
noindenttextbfExplaining the logic with an example:newline
The logic is a simple mathematical manipulation.newline
First, we need our three variables,
the total area we will call $area$ and the ratio $x : y$.newlinenewline
Let $area = 18$ and the ratio $x : y = 2 : 1$.newline
We know that $x times y = area$ or in other words, $2x times y = 18$.newline
For simplicity, let's only use one variable, $k$. Substitute $k$ newline
in our previous equation for both $x$ and $y$, $2k times k = 18$.newline
Solve for $k$:
beginalign*
2k times k &= 18\
2k^2 &= 18\
k^2 &= 9\
k &= 3
endalign*
Now, we multiply $k = 3$ in our original ratio $x : y = 2 : 1$.newline
Hence, our desired ratio is :
beginalign*
x : y &= 2(k) : 1(k)\
x : y &= 2(3) : 1(3)\
x : y &= 6 : 3\
endalign*bigskip
% Formal definition.
noindenttextbfFormal definition:newline
Let $area$ represent the total area of the image and the ratio $x : y$ respectively
represent the $width : height$ of the image.newline
Find a value $k$ such that $area = kx times ky$:
beginalign*
area &= (k)x times (k)y\
area &= k^2times (xy)\ % Step 1 (in the preamble) stores x*y.
fracareaxy &= k^2\ % Step 2 (in the preamble) stores area/(x*y)
sqrtfracareaxy &= k\% Step 3 (in the preamble) stores sqrt((area/(x*y)))
endalign*
Now, multiply $k$ by the our ratio given, $x : y$. % Steps 4 and 5 (in the preamble).
[kx : ky]
Which yields to $area = kx times ky$. hfill $blacksquare$
enddocument
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:46
I have updated the answer, check it out.
â M. Al Jumaily
Aug 20 at 5:17
1
You say that my desire is not achievable, but if you know an area A = W x H and an aspect ratio R = W / H, you can definitively find unique values for width W and height H, which is what I'm asking.
â mmj
Aug 20 at 22:06
Did you read all the post? If you elimanate the real values then sure, you can find a ratio assuming that W and H are not at the lowest ratio form, like W=2 and H=8... which you can have a reduced ratio of 1:4.... Now, if your ratio is 4:5, you cannot reduce it further because it's in the lowest form already... if you want you can enter the real values and divide it by 2 to obtain 2:2.5 but then you entered the real values where there are infinite solutions. You can divide by 2 or 3 or 4 or even 10000000^10000.... all are valid decimal ratios.
â M. Al Jumaily
Aug 20 at 22:06
1
I think there is a misunderstanding. The aspect ratio of an image is always a rational number. You cannot "reduce" the ratio because width x height must be equal to a given and arbitrary number, the area. My previous comment explain the simple math behind the question.
â mmj
Aug 20 at 22:17
 |Â
show 4 more comments
up vote
2
down vote
documentclass[12pt]article
usepackagegraphicx
begindocument
beginfigure% only needed if you want captions
includegraphics[width=linewidth]example-image-a
bigskip
makebox[linewidth]% only needed if the textwidth is smaller than the images
includegraphics[width=6cm,height=3cm,keepaspectratio=false]example-image-b
includegraphics[width=3.464cm,height=5.196cm,keepaspectratio=false]example-image-b
includegraphics[width=8cm,height=4cm,keepaspectratio=false]example-image-b%
endfigure
enddocument
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:45
1
then use[width=...,height=...,keepaspectratio=false]image
. see edited answer
â Herbert
Aug 19 at 17:23
2
I don't want to change the aspect ratio of images, I want a LaTeX command which use the aspect ratio R = W / H of image AND an area parameter A chosen by me, to calculate the width W and height H of image so that W x H = A and W / H = R.
â mmj
Aug 20 at 22:01
add a comment |Â
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
accepted
Here is an approach not redefining includegraphics
. However compared to scale
option, I cut a branch because I don't have details of graphicx.sty
in head, so possibly there would be a way to delegate to driver the final rescaling, which I am losing here. Ping @DavidCarlisle.
(I use xintexpr
but xfp
of course would do it as well as in Joseph's answer; also, up to some more cumbersome notations one could use only the macros of xintfrac
, giving a tiny speed-up as expression parsing is skipped).
documentclassarticle
usepackagegraphicx
usepackagexintexpr
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexxinttheiexpr[5]% round fixed point to 5
% fractional digits
dimexpr#1relax/
sqrt(Gin@nat@height*Gin@nat@width)
relax%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
newboxmybox
Equality only expected up to 5 digits of precision due to intrinsic
limitations of graphicx computations.
setboxmyboxhboxincludegraphics[sqrtofarea=2cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr2cmrelax*dimexpr2cmrelaxrelax (4cm$^2$)
setboxmyboxhboxincludegraphics[sqrtofarea=5cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr5cmrelax*dimexpr5cmrelaxrelax (25cm$^2$)
enddocument
The sentence at bottom of image must be amended: in TeX all dimensions are integer multiples of 1sp. When we set the area square root as key, we automatically limit the achievable precision of the area. For example 5cm
internally in TeX gives 9323399sp, hence a square equal to 86925768913201 as in image above. The previous square is 86925750266404 and the next one is 86925787560000, so they diverge in the 7th digit already and we can never overcome that possible imprecision when comparing a square with a produce height times width. Above we observe discrepancy already in 5th digit so the sentence is probably not completely wrong, but I felt I needed to add this mathematical precision.
Here is same with xfp
(basically copied from Joseph's way of using it):
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexfpeval#1/sqrt(Gin@nat@height*Gin@nat@width)%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
enddocument
About this:
no wrapping of
#1
indimexpr #1relax
needed here;xintexpr
could easily be extended to recognizecm
,in
,pt
, etc ... units so that e.g.2cm
is understood automatically, but the problem is that it would then do an exact conversion to a fractional number ofsp
units, whereas TeX process is more complex than simply using a proportionality factor and proceeds with rounding and truncating in various directions at various stages; so using exact conversion factor means not doing same operations as TeX itself. For this reason, no such units are defined yet inxintexpr
and user must go viadimexpr #1relax
; thexintexpr
parser will applynumber
to this, triggering TeX's own way to convert dimensional units.I am not expert in
xfp
so I don't know if sometimes such computation could result in a scientific notation which would break TeX later; in thexintexpr
solution I applied a transformation to fixed point value with 5 fractional digits. I don't know how one does that inxfp
and whether it could be needed here in some cases. In the MWE above it works fine.
It seems that I wrote too early about "optimal" solutions. Your solution as far as I understand adds thesqrtofarea
option (nice name, by the way) to standardincludegraphics
(which is better than adding a new command). I also tested thesqrtofarea
option together with the standardangle
option ofincludegraphics
ans it works, whereas if I add the sameangle
option when using the commandincludegraphicsbyarea
of other solutions I get an error.
â mmj
Aug 23 at 10:29
I think @DavidCarlisle should be pinged about correct way to add this option toincludegraphics
. Good to hear it works withangle
option. I added some mathematical comment at bottom of answer.
â jfbu
Aug 23 at 10:30
I think thatsqrtofarea
should definitively become a standard option ofincludegraphics
. Scaling by area is the best way of sizing many images different in size and aspect ratio so that they look approximately of the same size.
â mmj
Aug 23 at 10:47
unfortunately even with e-TeX'snumexpr, dimexpr
, it requires some work to avoid arithmetic overflows when implementing computations at low-level. Already graphicx/graphics has some extra code for obtaining ratio of two lengths which works well enough in 99.99% of real life situations, and is cleverly compact, but sqrtofarea requires extra implementation effort as it seems at least square root must be handled. Naturally graphicx will never load package like xint and all its unneeded macros. Perhaps in future it will have xfp automatically, then of course, sqrtofarea becomes feasible.
â jfbu
Aug 23 at 10:55
Maybesqrt(Gin@nat@height)*sqrt(Gin@nat@width)
would help in avoiding overflow? (I barely understand what you mean, sorry if I suggested something stupid).
â mmj
Aug 23 at 11:03
 |Â
show 1 more comment
up vote
4
down vote
accepted
Here is an approach not redefining includegraphics
. However compared to scale
option, I cut a branch because I don't have details of graphicx.sty
in head, so possibly there would be a way to delegate to driver the final rescaling, which I am losing here. Ping @DavidCarlisle.
(I use xintexpr
but xfp
of course would do it as well as in Joseph's answer; also, up to some more cumbersome notations one could use only the macros of xintfrac
, giving a tiny speed-up as expression parsing is skipped).
documentclassarticle
usepackagegraphicx
usepackagexintexpr
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexxinttheiexpr[5]% round fixed point to 5
% fractional digits
dimexpr#1relax/
sqrt(Gin@nat@height*Gin@nat@width)
relax%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
newboxmybox
Equality only expected up to 5 digits of precision due to intrinsic
limitations of graphicx computations.
setboxmyboxhboxincludegraphics[sqrtofarea=2cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr2cmrelax*dimexpr2cmrelaxrelax (4cm$^2$)
setboxmyboxhboxincludegraphics[sqrtofarea=5cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr5cmrelax*dimexpr5cmrelaxrelax (25cm$^2$)
enddocument
The sentence at bottom of image must be amended: in TeX all dimensions are integer multiples of 1sp. When we set the area square root as key, we automatically limit the achievable precision of the area. For example 5cm
internally in TeX gives 9323399sp, hence a square equal to 86925768913201 as in image above. The previous square is 86925750266404 and the next one is 86925787560000, so they diverge in the 7th digit already and we can never overcome that possible imprecision when comparing a square with a produce height times width. Above we observe discrepancy already in 5th digit so the sentence is probably not completely wrong, but I felt I needed to add this mathematical precision.
Here is same with xfp
(basically copied from Joseph's way of using it):
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexfpeval#1/sqrt(Gin@nat@height*Gin@nat@width)%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
enddocument
About this:
no wrapping of
#1
indimexpr #1relax
needed here;xintexpr
could easily be extended to recognizecm
,in
,pt
, etc ... units so that e.g.2cm
is understood automatically, but the problem is that it would then do an exact conversion to a fractional number ofsp
units, whereas TeX process is more complex than simply using a proportionality factor and proceeds with rounding and truncating in various directions at various stages; so using exact conversion factor means not doing same operations as TeX itself. For this reason, no such units are defined yet inxintexpr
and user must go viadimexpr #1relax
; thexintexpr
parser will applynumber
to this, triggering TeX's own way to convert dimensional units.I am not expert in
xfp
so I don't know if sometimes such computation could result in a scientific notation which would break TeX later; in thexintexpr
solution I applied a transformation to fixed point value with 5 fractional digits. I don't know how one does that inxfp
and whether it could be needed here in some cases. In the MWE above it works fine.
It seems that I wrote too early about "optimal" solutions. Your solution as far as I understand adds thesqrtofarea
option (nice name, by the way) to standardincludegraphics
(which is better than adding a new command). I also tested thesqrtofarea
option together with the standardangle
option ofincludegraphics
ans it works, whereas if I add the sameangle
option when using the commandincludegraphicsbyarea
of other solutions I get an error.
â mmj
Aug 23 at 10:29
I think @DavidCarlisle should be pinged about correct way to add this option toincludegraphics
. Good to hear it works withangle
option. I added some mathematical comment at bottom of answer.
â jfbu
Aug 23 at 10:30
I think thatsqrtofarea
should definitively become a standard option ofincludegraphics
. Scaling by area is the best way of sizing many images different in size and aspect ratio so that they look approximately of the same size.
â mmj
Aug 23 at 10:47
unfortunately even with e-TeX'snumexpr, dimexpr
, it requires some work to avoid arithmetic overflows when implementing computations at low-level. Already graphicx/graphics has some extra code for obtaining ratio of two lengths which works well enough in 99.99% of real life situations, and is cleverly compact, but sqrtofarea requires extra implementation effort as it seems at least square root must be handled. Naturally graphicx will never load package like xint and all its unneeded macros. Perhaps in future it will have xfp automatically, then of course, sqrtofarea becomes feasible.
â jfbu
Aug 23 at 10:55
Maybesqrt(Gin@nat@height)*sqrt(Gin@nat@width)
would help in avoiding overflow? (I barely understand what you mean, sorry if I suggested something stupid).
â mmj
Aug 23 at 11:03
 |Â
show 1 more comment
up vote
4
down vote
accepted
up vote
4
down vote
accepted
Here is an approach not redefining includegraphics
. However compared to scale
option, I cut a branch because I don't have details of graphicx.sty
in head, so possibly there would be a way to delegate to driver the final rescaling, which I am losing here. Ping @DavidCarlisle.
(I use xintexpr
but xfp
of course would do it as well as in Joseph's answer; also, up to some more cumbersome notations one could use only the macros of xintfrac
, giving a tiny speed-up as expression parsing is skipped).
documentclassarticle
usepackagegraphicx
usepackagexintexpr
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexxinttheiexpr[5]% round fixed point to 5
% fractional digits
dimexpr#1relax/
sqrt(Gin@nat@height*Gin@nat@width)
relax%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
newboxmybox
Equality only expected up to 5 digits of precision due to intrinsic
limitations of graphicx computations.
setboxmyboxhboxincludegraphics[sqrtofarea=2cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr2cmrelax*dimexpr2cmrelaxrelax (4cm$^2$)
setboxmyboxhboxincludegraphics[sqrtofarea=5cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr5cmrelax*dimexpr5cmrelaxrelax (25cm$^2$)
enddocument
The sentence at bottom of image must be amended: in TeX all dimensions are integer multiples of 1sp. When we set the area square root as key, we automatically limit the achievable precision of the area. For example 5cm
internally in TeX gives 9323399sp, hence a square equal to 86925768913201 as in image above. The previous square is 86925750266404 and the next one is 86925787560000, so they diverge in the 7th digit already and we can never overcome that possible imprecision when comparing a square with a produce height times width. Above we observe discrepancy already in 5th digit so the sentence is probably not completely wrong, but I felt I needed to add this mathematical precision.
Here is same with xfp
(basically copied from Joseph's way of using it):
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexfpeval#1/sqrt(Gin@nat@height*Gin@nat@width)%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
enddocument
About this:
no wrapping of
#1
indimexpr #1relax
needed here;xintexpr
could easily be extended to recognizecm
,in
,pt
, etc ... units so that e.g.2cm
is understood automatically, but the problem is that it would then do an exact conversion to a fractional number ofsp
units, whereas TeX process is more complex than simply using a proportionality factor and proceeds with rounding and truncating in various directions at various stages; so using exact conversion factor means not doing same operations as TeX itself. For this reason, no such units are defined yet inxintexpr
and user must go viadimexpr #1relax
; thexintexpr
parser will applynumber
to this, triggering TeX's own way to convert dimensional units.I am not expert in
xfp
so I don't know if sometimes such computation could result in a scientific notation which would break TeX later; in thexintexpr
solution I applied a transformation to fixed point value with 5 fractional digits. I don't know how one does that inxfp
and whether it could be needed here in some cases. In the MWE above it works fine.
Here is an approach not redefining includegraphics
. However compared to scale
option, I cut a branch because I don't have details of graphicx.sty
in head, so possibly there would be a way to delegate to driver the final rescaling, which I am losing here. Ping @DavidCarlisle.
(I use xintexpr
but xfp
of course would do it as well as in Joseph's answer; also, up to some more cumbersome notations one could use only the macros of xintfrac
, giving a tiny speed-up as expression parsing is skipped).
documentclassarticle
usepackagegraphicx
usepackagexintexpr
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexxinttheiexpr[5]% round fixed point to 5
% fractional digits
dimexpr#1relax/
sqrt(Gin@nat@height*Gin@nat@width)
relax%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
newboxmybox
Equality only expected up to 5 digits of precision due to intrinsic
limitations of graphicx computations.
setboxmyboxhboxincludegraphics[sqrtofarea=2cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr2cmrelax*dimexpr2cmrelaxrelax (4cm$^2$)
setboxmyboxhboxincludegraphics[sqrtofarea=5cm]example-image-a%
xinttheiiexprhtmybox*wdmyboxrelax
?=
xinttheiiexprdimexpr5cmrelax*dimexpr5cmrelaxrelax (25cm$^2$)
enddocument
The sentence at bottom of image must be amended: in TeX all dimensions are integer multiples of 1sp. When we set the area square root as key, we automatically limit the achievable precision of the area. For example 5cm
internally in TeX gives 9323399sp, hence a square equal to 86925768913201 as in image above. The previous square is 86925750266404 and the next one is 86925787560000, so they diverge in the 7th digit already and we can never overcome that possible imprecision when comparing a square with a produce height times width. Above we observe discrepancy already in 5th digit so the sentence is probably not completely wrong, but I felt I needed to add this mathematical precision.
Here is same with xfp
(basically copied from Joseph's way of using it):
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGinsqrtofarea%
defGin@req@sizes%
edefGin@scalexfpeval#1/sqrt(Gin@nat@height*Gin@nat@width)%
letGin@scaleyGin@exclamation
Gin@req@heightGin@scalexGin@nat@height
Gin@req@widthGin@scalexGin@nat@width
%
@tempswatrue
makeatother
begindocument
includegraphics[sqrtofarea=2cm]example-image-a
includegraphics[sqrtofarea=3cm]example-image-a
includegraphics[sqrtofarea=4cm]example-image-a
includegraphics[sqrtofarea=5cm]example-image-a
enddocument
About this:
no wrapping of
#1
indimexpr #1relax
needed here;xintexpr
could easily be extended to recognizecm
,in
,pt
, etc ... units so that e.g.2cm
is understood automatically, but the problem is that it would then do an exact conversion to a fractional number ofsp
units, whereas TeX process is more complex than simply using a proportionality factor and proceeds with rounding and truncating in various directions at various stages; so using exact conversion factor means not doing same operations as TeX itself. For this reason, no such units are defined yet inxintexpr
and user must go viadimexpr #1relax
; thexintexpr
parser will applynumber
to this, triggering TeX's own way to convert dimensional units.I am not expert in
xfp
so I don't know if sometimes such computation could result in a scientific notation which would break TeX later; in thexintexpr
solution I applied a transformation to fixed point value with 5 fractional digits. I don't know how one does that inxfp
and whether it could be needed here in some cases. In the MWE above it works fine.
edited Aug 23 at 16:41
answered Aug 23 at 9:48
jfbu
41.5k60131
41.5k60131
It seems that I wrote too early about "optimal" solutions. Your solution as far as I understand adds thesqrtofarea
option (nice name, by the way) to standardincludegraphics
(which is better than adding a new command). I also tested thesqrtofarea
option together with the standardangle
option ofincludegraphics
ans it works, whereas if I add the sameangle
option when using the commandincludegraphicsbyarea
of other solutions I get an error.
â mmj
Aug 23 at 10:29
I think @DavidCarlisle should be pinged about correct way to add this option toincludegraphics
. Good to hear it works withangle
option. I added some mathematical comment at bottom of answer.
â jfbu
Aug 23 at 10:30
I think thatsqrtofarea
should definitively become a standard option ofincludegraphics
. Scaling by area is the best way of sizing many images different in size and aspect ratio so that they look approximately of the same size.
â mmj
Aug 23 at 10:47
unfortunately even with e-TeX'snumexpr, dimexpr
, it requires some work to avoid arithmetic overflows when implementing computations at low-level. Already graphicx/graphics has some extra code for obtaining ratio of two lengths which works well enough in 99.99% of real life situations, and is cleverly compact, but sqrtofarea requires extra implementation effort as it seems at least square root must be handled. Naturally graphicx will never load package like xint and all its unneeded macros. Perhaps in future it will have xfp automatically, then of course, sqrtofarea becomes feasible.
â jfbu
Aug 23 at 10:55
Maybesqrt(Gin@nat@height)*sqrt(Gin@nat@width)
would help in avoiding overflow? (I barely understand what you mean, sorry if I suggested something stupid).
â mmj
Aug 23 at 11:03
 |Â
show 1 more comment
It seems that I wrote too early about "optimal" solutions. Your solution as far as I understand adds thesqrtofarea
option (nice name, by the way) to standardincludegraphics
(which is better than adding a new command). I also tested thesqrtofarea
option together with the standardangle
option ofincludegraphics
ans it works, whereas if I add the sameangle
option when using the commandincludegraphicsbyarea
of other solutions I get an error.
â mmj
Aug 23 at 10:29
I think @DavidCarlisle should be pinged about correct way to add this option toincludegraphics
. Good to hear it works withangle
option. I added some mathematical comment at bottom of answer.
â jfbu
Aug 23 at 10:30
I think thatsqrtofarea
should definitively become a standard option ofincludegraphics
. Scaling by area is the best way of sizing many images different in size and aspect ratio so that they look approximately of the same size.
â mmj
Aug 23 at 10:47
unfortunately even with e-TeX'snumexpr, dimexpr
, it requires some work to avoid arithmetic overflows when implementing computations at low-level. Already graphicx/graphics has some extra code for obtaining ratio of two lengths which works well enough in 99.99% of real life situations, and is cleverly compact, but sqrtofarea requires extra implementation effort as it seems at least square root must be handled. Naturally graphicx will never load package like xint and all its unneeded macros. Perhaps in future it will have xfp automatically, then of course, sqrtofarea becomes feasible.
â jfbu
Aug 23 at 10:55
Maybesqrt(Gin@nat@height)*sqrt(Gin@nat@width)
would help in avoiding overflow? (I barely understand what you mean, sorry if I suggested something stupid).
â mmj
Aug 23 at 11:03
It seems that I wrote too early about "optimal" solutions. Your solution as far as I understand adds the
sqrtofarea
option (nice name, by the way) to standard includegraphics
(which is better than adding a new command). I also tested the sqrtofarea
option together with the standard angle
option of includegraphics
ans it works, whereas if I add the same angle
option when using the command includegraphicsbyarea
of other solutions I get an error.â mmj
Aug 23 at 10:29
It seems that I wrote too early about "optimal" solutions. Your solution as far as I understand adds the
sqrtofarea
option (nice name, by the way) to standard includegraphics
(which is better than adding a new command). I also tested the sqrtofarea
option together with the standard angle
option of includegraphics
ans it works, whereas if I add the same angle
option when using the command includegraphicsbyarea
of other solutions I get an error.â mmj
Aug 23 at 10:29
I think @DavidCarlisle should be pinged about correct way to add this option to
includegraphics
. Good to hear it works with angle
option. I added some mathematical comment at bottom of answer.â jfbu
Aug 23 at 10:30
I think @DavidCarlisle should be pinged about correct way to add this option to
includegraphics
. Good to hear it works with angle
option. I added some mathematical comment at bottom of answer.â jfbu
Aug 23 at 10:30
I think that
sqrtofarea
should definitively become a standard option of includegraphics
. Scaling by area is the best way of sizing many images different in size and aspect ratio so that they look approximately of the same size.â mmj
Aug 23 at 10:47
I think that
sqrtofarea
should definitively become a standard option of includegraphics
. Scaling by area is the best way of sizing many images different in size and aspect ratio so that they look approximately of the same size.â mmj
Aug 23 at 10:47
unfortunately even with e-TeX's
numexpr, dimexpr
, it requires some work to avoid arithmetic overflows when implementing computations at low-level. Already graphicx/graphics has some extra code for obtaining ratio of two lengths which works well enough in 99.99% of real life situations, and is cleverly compact, but sqrtofarea requires extra implementation effort as it seems at least square root must be handled. Naturally graphicx will never load package like xint and all its unneeded macros. Perhaps in future it will have xfp automatically, then of course, sqrtofarea becomes feasible.â jfbu
Aug 23 at 10:55
unfortunately even with e-TeX's
numexpr, dimexpr
, it requires some work to avoid arithmetic overflows when implementing computations at low-level. Already graphicx/graphics has some extra code for obtaining ratio of two lengths which works well enough in 99.99% of real life situations, and is cleverly compact, but sqrtofarea requires extra implementation effort as it seems at least square root must be handled. Naturally graphicx will never load package like xint and all its unneeded macros. Perhaps in future it will have xfp automatically, then of course, sqrtofarea becomes feasible.â jfbu
Aug 23 at 10:55
Maybe
sqrt(Gin@nat@height)*sqrt(Gin@nat@width)
would help in avoiding overflow? (I barely understand what you mean, sorry if I suggested something stupid).â mmj
Aug 23 at 11:03
Maybe
sqrt(Gin@nat@height)*sqrt(Gin@nat@width)
would help in avoiding overflow? (I barely understand what you mean, sorry if I suggested something stupid).â mmj
Aug 23 at 11:03
 |Â
show 1 more comment
up vote
8
down vote
Scaling to an area is an unusual request: normally one knows the target height or width. The following takes the image and scales such that the area is that given in the optional argument, interpreted in square centimetres:
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareaareadefGarea@area#1
define@keyGareaareaunitdefGarea@unit#1
define@keyGinarea % So we can pass through easily
define@keyGinareaunit
newcommand*Garea@area
newcommand*Garea@unitcm
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@area@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalsqrt((Garea@area * 1 Garea@unit * 1 Garea@unit)
/(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[area=100]example-image-a
includegraphicsbyarea[area=100,areaunit=pt]example-image-a
enddocument
It still applies any options to the graphic: I've ordered such that the area scale is first, but one might want to put it last.
An alternative interface uses the square root of the area of the image: conveniently this has units we can work with directly
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareasqrtareadefGarea@sqrtarea#1
define@keyGinsqrtarea
newcommand*Garea@sqrtarea
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@diag@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalGarea@sqrtarea /(sqrt(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[sqrtarea = 5cm]example-image-a
includegraphicsbyarea[sqrtarea = 10cm]example-image-a
enddocument
(See the answer by mmj for an alternative name for the key.)
Your answer is clean and works well, but I would like to choose the unit of measure of the area. To obtain that it might be helpful using as parameter the square root of area instead of area. I think that using the square root of area is better, because to get a sense of the area you usually end up calculating the square root (I updated my question to underline that).
â mmj
Aug 20 at 22:05
I've added a follow up with an improved (IMHO) version of your solution. If you agree, please consider replacing your actual solution with that one, and I will delete the follow up, just for clarity towards future readers.
â mmj
Aug 22 at 12:23
@mmj I've added a version using the diagonal as the scaling determinant: that has a square-root relationship to area, and has units, and has a clear name :)
â Joseph Wrightâ¦
Aug 22 at 12:43
1
@mmj You'd be better to post your answer code as an answer, rather than edit it into the question. The site structure works best that way: as it stands, its a bit confusing.
â Joseph Wrightâ¦
Aug 22 at 12:44
Diagonal is a nice name and of course varies linearly with the width and height of an image, but it does not vary linearly when the aspect ratio changes, and the command is supposed to deal with images having different aspect ratios. What you call diagonal is actually the same parameter I used to modify your code, it is the square root of the area. Calling it diagonal is misleading the user because he/she might think that a 16x1 image and a 4x4 image will have the same diagonal, whereas they will have the same area (16) but very different diagonals, about 16 and 5.66 respectively.
â mmj
Aug 22 at 14:29
 |Â
show 6 more comments
up vote
8
down vote
Scaling to an area is an unusual request: normally one knows the target height or width. The following takes the image and scales such that the area is that given in the optional argument, interpreted in square centimetres:
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareaareadefGarea@area#1
define@keyGareaareaunitdefGarea@unit#1
define@keyGinarea % So we can pass through easily
define@keyGinareaunit
newcommand*Garea@area
newcommand*Garea@unitcm
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@area@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalsqrt((Garea@area * 1 Garea@unit * 1 Garea@unit)
/(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[area=100]example-image-a
includegraphicsbyarea[area=100,areaunit=pt]example-image-a
enddocument
It still applies any options to the graphic: I've ordered such that the area scale is first, but one might want to put it last.
An alternative interface uses the square root of the area of the image: conveniently this has units we can work with directly
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareasqrtareadefGarea@sqrtarea#1
define@keyGinsqrtarea
newcommand*Garea@sqrtarea
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@diag@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalGarea@sqrtarea /(sqrt(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[sqrtarea = 5cm]example-image-a
includegraphicsbyarea[sqrtarea = 10cm]example-image-a
enddocument
(See the answer by mmj for an alternative name for the key.)
Your answer is clean and works well, but I would like to choose the unit of measure of the area. To obtain that it might be helpful using as parameter the square root of area instead of area. I think that using the square root of area is better, because to get a sense of the area you usually end up calculating the square root (I updated my question to underline that).
â mmj
Aug 20 at 22:05
I've added a follow up with an improved (IMHO) version of your solution. If you agree, please consider replacing your actual solution with that one, and I will delete the follow up, just for clarity towards future readers.
â mmj
Aug 22 at 12:23
@mmj I've added a version using the diagonal as the scaling determinant: that has a square-root relationship to area, and has units, and has a clear name :)
â Joseph Wrightâ¦
Aug 22 at 12:43
1
@mmj You'd be better to post your answer code as an answer, rather than edit it into the question. The site structure works best that way: as it stands, its a bit confusing.
â Joseph Wrightâ¦
Aug 22 at 12:44
Diagonal is a nice name and of course varies linearly with the width and height of an image, but it does not vary linearly when the aspect ratio changes, and the command is supposed to deal with images having different aspect ratios. What you call diagonal is actually the same parameter I used to modify your code, it is the square root of the area. Calling it diagonal is misleading the user because he/she might think that a 16x1 image and a 4x4 image will have the same diagonal, whereas they will have the same area (16) but very different diagonals, about 16 and 5.66 respectively.
â mmj
Aug 22 at 14:29
 |Â
show 6 more comments
up vote
8
down vote
up vote
8
down vote
Scaling to an area is an unusual request: normally one knows the target height or width. The following takes the image and scales such that the area is that given in the optional argument, interpreted in square centimetres:
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareaareadefGarea@area#1
define@keyGareaareaunitdefGarea@unit#1
define@keyGinarea % So we can pass through easily
define@keyGinareaunit
newcommand*Garea@area
newcommand*Garea@unitcm
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@area@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalsqrt((Garea@area * 1 Garea@unit * 1 Garea@unit)
/(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[area=100]example-image-a
includegraphicsbyarea[area=100,areaunit=pt]example-image-a
enddocument
It still applies any options to the graphic: I've ordered such that the area scale is first, but one might want to put it last.
An alternative interface uses the square root of the area of the image: conveniently this has units we can work with directly
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareasqrtareadefGarea@sqrtarea#1
define@keyGinsqrtarea
newcommand*Garea@sqrtarea
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@diag@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalGarea@sqrtarea /(sqrt(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[sqrtarea = 5cm]example-image-a
includegraphicsbyarea[sqrtarea = 10cm]example-image-a
enddocument
(See the answer by mmj for an alternative name for the key.)
Scaling to an area is an unusual request: normally one knows the target height or width. The following takes the image and scales such that the area is that given in the optional argument, interpreted in square centimetres:
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareaareadefGarea@area#1
define@keyGareaareaunitdefGarea@unit#1
define@keyGinarea % So we can pass through easily
define@keyGinareaunit
newcommand*Garea@area
newcommand*Garea@unitcm
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@area@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalsqrt((Garea@area * 1 Garea@unit * 1 Garea@unit)
/(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[area=100]example-image-a
includegraphicsbyarea[area=100,areaunit=pt]example-image-a
enddocument
It still applies any options to the graphic: I've ordered such that the area scale is first, but one might want to put it last.
An alternative interface uses the square root of the area of the image: conveniently this has units we can work with directly
documentclassarticle
usepackagegraphicx
usepackagexfp
makeatletter
define@keyGareasqrtareadefGarea@sqrtarea#1
define@keyGinsqrtarea
newcommand*Garea@sqrtarea
newcommandincludegraphicsbyarea[2]%
setkeysGarea#1%
ifxGarea@diag@empty
gdefGarea@scalescale = 1%
else
begingroup
setbox0=hboxincludegraphics[#1]#2%
xdefGarea@scalescale =
fpevalGarea@sqrtarea /(sqrt(theht0 * thewd0))%
endgroup
fi
expandafterincludegraphicsexpandafter[Garea@scale,#1]#2%
makeatother
begindocument
includegraphicsbyarea[sqrtarea = 5cm]example-image-a
includegraphicsbyarea[sqrtarea = 10cm]example-image-a
enddocument
(See the answer by mmj for an alternative name for the key.)
edited Aug 23 at 14:57
answered Aug 19 at 19:26
Joseph Wrightâ¦
196k21540860
196k21540860
Your answer is clean and works well, but I would like to choose the unit of measure of the area. To obtain that it might be helpful using as parameter the square root of area instead of area. I think that using the square root of area is better, because to get a sense of the area you usually end up calculating the square root (I updated my question to underline that).
â mmj
Aug 20 at 22:05
I've added a follow up with an improved (IMHO) version of your solution. If you agree, please consider replacing your actual solution with that one, and I will delete the follow up, just for clarity towards future readers.
â mmj
Aug 22 at 12:23
@mmj I've added a version using the diagonal as the scaling determinant: that has a square-root relationship to area, and has units, and has a clear name :)
â Joseph Wrightâ¦
Aug 22 at 12:43
1
@mmj You'd be better to post your answer code as an answer, rather than edit it into the question. The site structure works best that way: as it stands, its a bit confusing.
â Joseph Wrightâ¦
Aug 22 at 12:44
Diagonal is a nice name and of course varies linearly with the width and height of an image, but it does not vary linearly when the aspect ratio changes, and the command is supposed to deal with images having different aspect ratios. What you call diagonal is actually the same parameter I used to modify your code, it is the square root of the area. Calling it diagonal is misleading the user because he/she might think that a 16x1 image and a 4x4 image will have the same diagonal, whereas they will have the same area (16) but very different diagonals, about 16 and 5.66 respectively.
â mmj
Aug 22 at 14:29
 |Â
show 6 more comments
Your answer is clean and works well, but I would like to choose the unit of measure of the area. To obtain that it might be helpful using as parameter the square root of area instead of area. I think that using the square root of area is better, because to get a sense of the area you usually end up calculating the square root (I updated my question to underline that).
â mmj
Aug 20 at 22:05
I've added a follow up with an improved (IMHO) version of your solution. If you agree, please consider replacing your actual solution with that one, and I will delete the follow up, just for clarity towards future readers.
â mmj
Aug 22 at 12:23
@mmj I've added a version using the diagonal as the scaling determinant: that has a square-root relationship to area, and has units, and has a clear name :)
â Joseph Wrightâ¦
Aug 22 at 12:43
1
@mmj You'd be better to post your answer code as an answer, rather than edit it into the question. The site structure works best that way: as it stands, its a bit confusing.
â Joseph Wrightâ¦
Aug 22 at 12:44
Diagonal is a nice name and of course varies linearly with the width and height of an image, but it does not vary linearly when the aspect ratio changes, and the command is supposed to deal with images having different aspect ratios. What you call diagonal is actually the same parameter I used to modify your code, it is the square root of the area. Calling it diagonal is misleading the user because he/she might think that a 16x1 image and a 4x4 image will have the same diagonal, whereas they will have the same area (16) but very different diagonals, about 16 and 5.66 respectively.
â mmj
Aug 22 at 14:29
Your answer is clean and works well, but I would like to choose the unit of measure of the area. To obtain that it might be helpful using as parameter the square root of area instead of area. I think that using the square root of area is better, because to get a sense of the area you usually end up calculating the square root (I updated my question to underline that).
â mmj
Aug 20 at 22:05
Your answer is clean and works well, but I would like to choose the unit of measure of the area. To obtain that it might be helpful using as parameter the square root of area instead of area. I think that using the square root of area is better, because to get a sense of the area you usually end up calculating the square root (I updated my question to underline that).
â mmj
Aug 20 at 22:05
I've added a follow up with an improved (IMHO) version of your solution. If you agree, please consider replacing your actual solution with that one, and I will delete the follow up, just for clarity towards future readers.
â mmj
Aug 22 at 12:23
I've added a follow up with an improved (IMHO) version of your solution. If you agree, please consider replacing your actual solution with that one, and I will delete the follow up, just for clarity towards future readers.
â mmj
Aug 22 at 12:23
@mmj I've added a version using the diagonal as the scaling determinant: that has a square-root relationship to area, and has units, and has a clear name :)
â Joseph Wrightâ¦
Aug 22 at 12:43
@mmj I've added a version using the diagonal as the scaling determinant: that has a square-root relationship to area, and has units, and has a clear name :)
â Joseph Wrightâ¦
Aug 22 at 12:43
1
1
@mmj You'd be better to post your answer code as an answer, rather than edit it into the question. The site structure works best that way: as it stands, its a bit confusing.
â Joseph Wrightâ¦
Aug 22 at 12:44
@mmj You'd be better to post your answer code as an answer, rather than edit it into the question. The site structure works best that way: as it stands, its a bit confusing.
â Joseph Wrightâ¦
Aug 22 at 12:44
Diagonal is a nice name and of course varies linearly with the width and height of an image, but it does not vary linearly when the aspect ratio changes, and the command is supposed to deal with images having different aspect ratios. What you call diagonal is actually the same parameter I used to modify your code, it is the square root of the area. Calling it diagonal is misleading the user because he/she might think that a 16x1 image and a 4x4 image will have the same diagonal, whereas they will have the same area (16) but very different diagonals, about 16 and 5.66 respectively.
â mmj
Aug 22 at 14:29
Diagonal is a nice name and of course varies linearly with the width and height of an image, but it does not vary linearly when the aspect ratio changes, and the command is supposed to deal with images having different aspect ratios. What you call diagonal is actually the same parameter I used to modify your code, it is the square root of the area. Calling it diagonal is misleading the user because he/she might think that a 16x1 image and a 4x4 image will have the same diagonal, whereas they will have the same area (16) but very different diagonals, about 16 and 5.66 respectively.
â mmj
Aug 22 at 14:29
 |Â
show 6 more comments
up vote
6
down vote
Update 3
This is the last revision, I promise.
The only change is the use of pgfmath.sty
in place of fp-eval.sty
which, in turn, required a little special handling to avoid dimension too large
errors. As well, the use of pgfmath.sty
allowed for considerable simplification. The new output is identical to the old.
%===8><-----%
I was unhappy with the way that I left the scaletoarea macro. It has been altered to be, hopefully, a little more user-friendly. I have made it possible to use the options to includegraphics
for all of the macros. Take a look at the examples.
%===8><---%
I take it that you want all of the graphics to have the same area regardless of the aspect ratio. The following code does that.
There are two approaches outlined here.
The first scales subsequent graphics based on the size of the first graphic Use fpic
for the first graphic; using spic
for the subsequent graphics will size them to have the same area as the first graphic. Use the options to fpic
(the same as those to includegraphics
) to size the first graphic accordingly.
Second, if you know the target area, you can use scaletoarea<unitless area><linear unit of area><name of graphic>
. For example, if you were to scale a graphic, foo
, so that it is 5 square inches in area, you would write: scaletoarea5infoo
. Any of the units recognized by TeX can be used.
documentclassarticle
usepackagegraphicx,calc,pgfmath
usepackage[margin=0.5in]geometry
newlengthfpicw
newlengthfpich
newlengthspicw
newlengthspich
newsaveboxfirstpic
newsaveboxnextpics
newlengthtargetarea
%% fpic[<options to includegraphics>]<name of graphic>
newcommandfpic[2]% First picture, use includegraphics, and options
sboxfirstpicincludegraphics[#1]#2%
settoheightfpichuseboxfirstpic%
settowidthfpicwuseboxfirstpic%
useboxfirstpic%
%% spic[<options to includegraphics>]<graphic name>
newcommandspic[2]% Second and succeeding pictures
sboxnextpicsincludegraphics[#1]#2%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((fpicw/spicw)*(fpich/spich))%
scaleboxscalinguseboxnextpics%
typeout**The scaling (#2) = scaling% Comment-out if not needed
%% scaletoarea[<options to includegraphics>]<unitless area><unit of area (linear)><graphic name>
newcommandscaletoarea[4]%
pgfmathsetmacromytmpsqrt(#2)%
setlengthtargetareamytmp #3%
sboxnextpicsincludegraphics[#1]#4%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
typeout++The scaling (#4) = scaling% Comment-out if not needed
%% scaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
newcommandscaletoareab[3]%
setlengthtargetarea#2%
sboxnextpicsincludegraphics[#1]#3%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
message++The scaling (#3) = numberscaling%
begindocument
fpic[width=1.25in]PeppersspicPastaspicOldImagespicBethanyDrawing
scaletoarea3inPeppersscaletoarea12cmPastascaletoarea2inOldImagescaletoarea61pcBethanyDrawing
scaletoarea[width=0.5in,height=3in,keepaspectratio=false]3inPeppers
scaletoareab[width=0.5in,height=3in,keepaspectratio=false]1.732050807568877inPeppers
enddocument
My math was wrong forscaletoarea
. The first argument toscaletoarea
should be the square root of the desired area. Made the correction in the code listing.
â sgmoye
Aug 19 at 18:45
I have modified my original answer to modify howscaletoarea
works.
â sgmoye
Aug 20 at 11:58
I tested the previous version of yourscaletoarea
command and it worked well, but above all I liked the use of square root of area as parameter instead of area. In fact using the square root of area is better, because to get a sense of the area you have in any case to calculate the square root. And you save a parameter in comparison to the new current version that needs an additional parameter for the unit of measure. Please consider restoring the use of square root of area as parameter forscaletoarea
command.
â mmj
Aug 20 at 21:31
I'm a little tied up now, but I will get to it later today or tomorrow. Thanks.
â sgmoye
Aug 20 at 22:28
@mmj Check now. The macro (last one in the code) isscaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
. Included example and output.
â sgmoye
Aug 21 at 0:41
 |Â
show 1 more comment
up vote
6
down vote
Update 3
This is the last revision, I promise.
The only change is the use of pgfmath.sty
in place of fp-eval.sty
which, in turn, required a little special handling to avoid dimension too large
errors. As well, the use of pgfmath.sty
allowed for considerable simplification. The new output is identical to the old.
%===8><-----%
I was unhappy with the way that I left the scaletoarea macro. It has been altered to be, hopefully, a little more user-friendly. I have made it possible to use the options to includegraphics
for all of the macros. Take a look at the examples.
%===8><---%
I take it that you want all of the graphics to have the same area regardless of the aspect ratio. The following code does that.
There are two approaches outlined here.
The first scales subsequent graphics based on the size of the first graphic Use fpic
for the first graphic; using spic
for the subsequent graphics will size them to have the same area as the first graphic. Use the options to fpic
(the same as those to includegraphics
) to size the first graphic accordingly.
Second, if you know the target area, you can use scaletoarea<unitless area><linear unit of area><name of graphic>
. For example, if you were to scale a graphic, foo
, so that it is 5 square inches in area, you would write: scaletoarea5infoo
. Any of the units recognized by TeX can be used.
documentclassarticle
usepackagegraphicx,calc,pgfmath
usepackage[margin=0.5in]geometry
newlengthfpicw
newlengthfpich
newlengthspicw
newlengthspich
newsaveboxfirstpic
newsaveboxnextpics
newlengthtargetarea
%% fpic[<options to includegraphics>]<name of graphic>
newcommandfpic[2]% First picture, use includegraphics, and options
sboxfirstpicincludegraphics[#1]#2%
settoheightfpichuseboxfirstpic%
settowidthfpicwuseboxfirstpic%
useboxfirstpic%
%% spic[<options to includegraphics>]<graphic name>
newcommandspic[2]% Second and succeeding pictures
sboxnextpicsincludegraphics[#1]#2%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((fpicw/spicw)*(fpich/spich))%
scaleboxscalinguseboxnextpics%
typeout**The scaling (#2) = scaling% Comment-out if not needed
%% scaletoarea[<options to includegraphics>]<unitless area><unit of area (linear)><graphic name>
newcommandscaletoarea[4]%
pgfmathsetmacromytmpsqrt(#2)%
setlengthtargetareamytmp #3%
sboxnextpicsincludegraphics[#1]#4%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
typeout++The scaling (#4) = scaling% Comment-out if not needed
%% scaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
newcommandscaletoareab[3]%
setlengthtargetarea#2%
sboxnextpicsincludegraphics[#1]#3%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
message++The scaling (#3) = numberscaling%
begindocument
fpic[width=1.25in]PeppersspicPastaspicOldImagespicBethanyDrawing
scaletoarea3inPeppersscaletoarea12cmPastascaletoarea2inOldImagescaletoarea61pcBethanyDrawing
scaletoarea[width=0.5in,height=3in,keepaspectratio=false]3inPeppers
scaletoareab[width=0.5in,height=3in,keepaspectratio=false]1.732050807568877inPeppers
enddocument
My math was wrong forscaletoarea
. The first argument toscaletoarea
should be the square root of the desired area. Made the correction in the code listing.
â sgmoye
Aug 19 at 18:45
I have modified my original answer to modify howscaletoarea
works.
â sgmoye
Aug 20 at 11:58
I tested the previous version of yourscaletoarea
command and it worked well, but above all I liked the use of square root of area as parameter instead of area. In fact using the square root of area is better, because to get a sense of the area you have in any case to calculate the square root. And you save a parameter in comparison to the new current version that needs an additional parameter for the unit of measure. Please consider restoring the use of square root of area as parameter forscaletoarea
command.
â mmj
Aug 20 at 21:31
I'm a little tied up now, but I will get to it later today or tomorrow. Thanks.
â sgmoye
Aug 20 at 22:28
@mmj Check now. The macro (last one in the code) isscaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
. Included example and output.
â sgmoye
Aug 21 at 0:41
 |Â
show 1 more comment
up vote
6
down vote
up vote
6
down vote
Update 3
This is the last revision, I promise.
The only change is the use of pgfmath.sty
in place of fp-eval.sty
which, in turn, required a little special handling to avoid dimension too large
errors. As well, the use of pgfmath.sty
allowed for considerable simplification. The new output is identical to the old.
%===8><-----%
I was unhappy with the way that I left the scaletoarea macro. It has been altered to be, hopefully, a little more user-friendly. I have made it possible to use the options to includegraphics
for all of the macros. Take a look at the examples.
%===8><---%
I take it that you want all of the graphics to have the same area regardless of the aspect ratio. The following code does that.
There are two approaches outlined here.
The first scales subsequent graphics based on the size of the first graphic Use fpic
for the first graphic; using spic
for the subsequent graphics will size them to have the same area as the first graphic. Use the options to fpic
(the same as those to includegraphics
) to size the first graphic accordingly.
Second, if you know the target area, you can use scaletoarea<unitless area><linear unit of area><name of graphic>
. For example, if you were to scale a graphic, foo
, so that it is 5 square inches in area, you would write: scaletoarea5infoo
. Any of the units recognized by TeX can be used.
documentclassarticle
usepackagegraphicx,calc,pgfmath
usepackage[margin=0.5in]geometry
newlengthfpicw
newlengthfpich
newlengthspicw
newlengthspich
newsaveboxfirstpic
newsaveboxnextpics
newlengthtargetarea
%% fpic[<options to includegraphics>]<name of graphic>
newcommandfpic[2]% First picture, use includegraphics, and options
sboxfirstpicincludegraphics[#1]#2%
settoheightfpichuseboxfirstpic%
settowidthfpicwuseboxfirstpic%
useboxfirstpic%
%% spic[<options to includegraphics>]<graphic name>
newcommandspic[2]% Second and succeeding pictures
sboxnextpicsincludegraphics[#1]#2%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((fpicw/spicw)*(fpich/spich))%
scaleboxscalinguseboxnextpics%
typeout**The scaling (#2) = scaling% Comment-out if not needed
%% scaletoarea[<options to includegraphics>]<unitless area><unit of area (linear)><graphic name>
newcommandscaletoarea[4]%
pgfmathsetmacromytmpsqrt(#2)%
setlengthtargetareamytmp #3%
sboxnextpicsincludegraphics[#1]#4%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
typeout++The scaling (#4) = scaling% Comment-out if not needed
%% scaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
newcommandscaletoareab[3]%
setlengthtargetarea#2%
sboxnextpicsincludegraphics[#1]#3%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
message++The scaling (#3) = numberscaling%
begindocument
fpic[width=1.25in]PeppersspicPastaspicOldImagespicBethanyDrawing
scaletoarea3inPeppersscaletoarea12cmPastascaletoarea2inOldImagescaletoarea61pcBethanyDrawing
scaletoarea[width=0.5in,height=3in,keepaspectratio=false]3inPeppers
scaletoareab[width=0.5in,height=3in,keepaspectratio=false]1.732050807568877inPeppers
enddocument
Update 3
This is the last revision, I promise.
The only change is the use of pgfmath.sty
in place of fp-eval.sty
which, in turn, required a little special handling to avoid dimension too large
errors. As well, the use of pgfmath.sty
allowed for considerable simplification. The new output is identical to the old.
%===8><-----%
I was unhappy with the way that I left the scaletoarea macro. It has been altered to be, hopefully, a little more user-friendly. I have made it possible to use the options to includegraphics
for all of the macros. Take a look at the examples.
%===8><---%
I take it that you want all of the graphics to have the same area regardless of the aspect ratio. The following code does that.
There are two approaches outlined here.
The first scales subsequent graphics based on the size of the first graphic Use fpic
for the first graphic; using spic
for the subsequent graphics will size them to have the same area as the first graphic. Use the options to fpic
(the same as those to includegraphics
) to size the first graphic accordingly.
Second, if you know the target area, you can use scaletoarea<unitless area><linear unit of area><name of graphic>
. For example, if you were to scale a graphic, foo
, so that it is 5 square inches in area, you would write: scaletoarea5infoo
. Any of the units recognized by TeX can be used.
documentclassarticle
usepackagegraphicx,calc,pgfmath
usepackage[margin=0.5in]geometry
newlengthfpicw
newlengthfpich
newlengthspicw
newlengthspich
newsaveboxfirstpic
newsaveboxnextpics
newlengthtargetarea
%% fpic[<options to includegraphics>]<name of graphic>
newcommandfpic[2]% First picture, use includegraphics, and options
sboxfirstpicincludegraphics[#1]#2%
settoheightfpichuseboxfirstpic%
settowidthfpicwuseboxfirstpic%
useboxfirstpic%
%% spic[<options to includegraphics>]<graphic name>
newcommandspic[2]% Second and succeeding pictures
sboxnextpicsincludegraphics[#1]#2%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((fpicw/spicw)*(fpich/spich))%
scaleboxscalinguseboxnextpics%
typeout**The scaling (#2) = scaling% Comment-out if not needed
%% scaletoarea[<options to includegraphics>]<unitless area><unit of area (linear)><graphic name>
newcommandscaletoarea[4]%
pgfmathsetmacromytmpsqrt(#2)%
setlengthtargetareamytmp #3%
sboxnextpicsincludegraphics[#1]#4%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
typeout++The scaling (#4) = scaling% Comment-out if not needed
%% scaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
newcommandscaletoareab[3]%
setlengthtargetarea#2%
sboxnextpicsincludegraphics[#1]#3%
settoheightspichuseboxnextpics%
settowidthspicwuseboxnextpics%
pgfmathsetmacroscalingsqrt((targetarea/spicw)*(targetarea/spich))%
scaleboxscalinguseboxnextpics%
message++The scaling (#3) = numberscaling%
begindocument
fpic[width=1.25in]PeppersspicPastaspicOldImagespicBethanyDrawing
scaletoarea3inPeppersscaletoarea12cmPastascaletoarea2inOldImagescaletoarea61pcBethanyDrawing
scaletoarea[width=0.5in,height=3in,keepaspectratio=false]3inPeppers
scaletoareab[width=0.5in,height=3in,keepaspectratio=false]1.732050807568877inPeppers
enddocument
edited Aug 21 at 0:37
answered Aug 19 at 16:21
sgmoye
3,57811125
3,57811125
My math was wrong forscaletoarea
. The first argument toscaletoarea
should be the square root of the desired area. Made the correction in the code listing.
â sgmoye
Aug 19 at 18:45
I have modified my original answer to modify howscaletoarea
works.
â sgmoye
Aug 20 at 11:58
I tested the previous version of yourscaletoarea
command and it worked well, but above all I liked the use of square root of area as parameter instead of area. In fact using the square root of area is better, because to get a sense of the area you have in any case to calculate the square root. And you save a parameter in comparison to the new current version that needs an additional parameter for the unit of measure. Please consider restoring the use of square root of area as parameter forscaletoarea
command.
â mmj
Aug 20 at 21:31
I'm a little tied up now, but I will get to it later today or tomorrow. Thanks.
â sgmoye
Aug 20 at 22:28
@mmj Check now. The macro (last one in the code) isscaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
. Included example and output.
â sgmoye
Aug 21 at 0:41
 |Â
show 1 more comment
My math was wrong forscaletoarea
. The first argument toscaletoarea
should be the square root of the desired area. Made the correction in the code listing.
â sgmoye
Aug 19 at 18:45
I have modified my original answer to modify howscaletoarea
works.
â sgmoye
Aug 20 at 11:58
I tested the previous version of yourscaletoarea
command and it worked well, but above all I liked the use of square root of area as parameter instead of area. In fact using the square root of area is better, because to get a sense of the area you have in any case to calculate the square root. And you save a parameter in comparison to the new current version that needs an additional parameter for the unit of measure. Please consider restoring the use of square root of area as parameter forscaletoarea
command.
â mmj
Aug 20 at 21:31
I'm a little tied up now, but I will get to it later today or tomorrow. Thanks.
â sgmoye
Aug 20 at 22:28
@mmj Check now. The macro (last one in the code) isscaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
. Included example and output.
â sgmoye
Aug 21 at 0:41
My math was wrong for
scaletoarea
. The first argument to scaletoarea
should be the square root of the desired area. Made the correction in the code listing.â sgmoye
Aug 19 at 18:45
My math was wrong for
scaletoarea
. The first argument to scaletoarea
should be the square root of the desired area. Made the correction in the code listing.â sgmoye
Aug 19 at 18:45
I have modified my original answer to modify how
scaletoarea
works.â sgmoye
Aug 20 at 11:58
I have modified my original answer to modify how
scaletoarea
works.â sgmoye
Aug 20 at 11:58
I tested the previous version of your
scaletoarea
command and it worked well, but above all I liked the use of square root of area as parameter instead of area. In fact using the square root of area is better, because to get a sense of the area you have in any case to calculate the square root. And you save a parameter in comparison to the new current version that needs an additional parameter for the unit of measure. Please consider restoring the use of square root of area as parameter for scaletoarea
command.â mmj
Aug 20 at 21:31
I tested the previous version of your
scaletoarea
command and it worked well, but above all I liked the use of square root of area as parameter instead of area. In fact using the square root of area is better, because to get a sense of the area you have in any case to calculate the square root. And you save a parameter in comparison to the new current version that needs an additional parameter for the unit of measure. Please consider restoring the use of square root of area as parameter for scaletoarea
command.â mmj
Aug 20 at 21:31
I'm a little tied up now, but I will get to it later today or tomorrow. Thanks.
â sgmoye
Aug 20 at 22:28
I'm a little tied up now, but I will get to it later today or tomorrow. Thanks.
â sgmoye
Aug 20 at 22:28
@mmj Check now. The macro (last one in the code) is
scaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
. Included example and output.â sgmoye
Aug 21 at 0:41
@mmj Check now. The macro (last one in the code) is
scaletoareab[<options to includegraphics>]<square root of desired area><name of graphic>
. Included example and output.â sgmoye
Aug 21 at 0:41
 |Â
show 1 more comment
up vote
3
down vote
Here is an MCVE that fulfills your requirements provided th. I have also added commented the code and added a full explanation with regards to the logic of the program.
Sample output:
Now the explanation:
The code!:
documentclass[12pt]article
usepackagegraphicx, color
usepackage[margin=0.5in]geometry
usepackagecalculator % Very important package. Provides
% basic mathematical operations like
% addition, subtracting, multiplying
% dividing, rounding, truncating, and
% finding the GCD (greatest common divisor).
usepackagecaption, amsmath, amssymb
makeatletter
newcommand*getlength[1]strip@pt#1
makeatother
% For the area, and ratio (width:height) = (xRatio:yRatio)
newlengthareaGiven
newlengthxRatio
newlengthyRatio
% Accepts 4 argments: area, width ratio, height ratio, and name of image (respectively).
newcommand*adjustImage[4]%
setlengthareaGiven#1 cm
setlengthxRatio#2 cm
setlengthyRatio#3 cm
noindent Given information~~~~~~~~~~~: textbfarea = #1cm,
textbfratio $(width:height) = #2:#3$.
% Convert the unit from pt to cm. Note, 1pt = 0.0352778cm.
% If you really care about exact numbers, 1.0000008pt = 0.035277806cm.
% If inches is the unit to focus on, then change 0.0352778 to 0.0138889.
MULTIPLYgetlengthareaGiven0.0352778areaInCm
MULTIPLYgetlengthxRatio0.0352778xRatioInCm
MULTIPLYgetlengthyRatio0.0352778yRatioInCm
noindent Converting from pt to cm : textbfarea = areaInCm cm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% Keep in mind that there will be rounding errors. The answer
% we will obtain is a decimal answer. Since pixels are atomic, we need to
% truncate (or round) the decimal values to secure a whole number.
% I used the TRUNCATE command, you can comment the next three line and
% uncomment the ROUND commands if you want to round.
TRUNCATE[0]areaInCmareaInCm
TRUNCATE[0]xRatioInCmxRatioInCm
TRUNCATE[0]yRatioInCmyRatioInCm
% OR use round instead. It is better for images with areas 100+.
% ROUND[0]areaInCmareaInCm
% ROUND[0]xRatioInCmxRatioInCm
% ROUND[0]yRatioInCmyRatioInCm
noindent After truncating~~~~~~~~~~~~~: textbfarea = areaInCm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% The following are the steps of find the result mathematically.
% This is explained in details at the end of the docmument.
MULTIPLYxRatioInCmyRatioInCmk % 1) finds (a*b) in ak*bk = area.
DIVIDEareaInCmkk % 2) finds (area/(a*b)) in k^2 = (area/(a*b)).
SQUAREROOTkkFinal % 3) finds of k in k = sqrt((area/(a*b))).
MULTIPLYxRatioInCmkFinalx % 4) multiplies the x-ratio by k.
MULTIPLYyRatioInCmkFinaly % 5) multiplies the y-ratio by k.
noindent textbfFinal dimensions are~~~:
textbfwidth = x cm, textbfheight = y cm.
begincenter
includegraphics[width = x cm, height = y cm]#4 % 6*3 cm
captionoffigure
textbfarea = #1cm, textbfratio
$(width:height) = #2:#3$ $longrightarrow$
textbfwidth = x cm, textbfheight = y cm.
endcenter
begindocument
noindent
textcolorredtextbfExample A:newline
adjustImage1821example-image-a % area = 18cm, ratio (width:height) = 2:1
textcolorredtextbfExample B:newline
adjustImage1823example-image-b % area = 18cm, ratio (width:height) = 2:3
textcolorredtextbfExample C:newline
adjustImage3221example-image-c % area = 32cm, ratio (width:height) = 2:1
% Maximum area is 575 units!
% adjustImage57521TestImage.png % area = 575cm, ratio (width:height) = 2:1
newpage
newgeometrymargin=1in
% Here is the explanation of the logic.
noindenttextbfExplaining the logic with an example:newline
The logic is a simple mathematical manipulation.newline
First, we need our three variables,
the total area we will call $area$ and the ratio $x : y$.newlinenewline
Let $area = 18$ and the ratio $x : y = 2 : 1$.newline
We know that $x times y = area$ or in other words, $2x times y = 18$.newline
For simplicity, let's only use one variable, $k$. Substitute $k$ newline
in our previous equation for both $x$ and $y$, $2k times k = 18$.newline
Solve for $k$:
beginalign*
2k times k &= 18\
2k^2 &= 18\
k^2 &= 9\
k &= 3
endalign*
Now, we multiply $k = 3$ in our original ratio $x : y = 2 : 1$.newline
Hence, our desired ratio is :
beginalign*
x : y &= 2(k) : 1(k)\
x : y &= 2(3) : 1(3)\
x : y &= 6 : 3\
endalign*bigskip
% Formal definition.
noindenttextbfFormal definition:newline
Let $area$ represent the total area of the image and the ratio $x : y$ respectively
represent the $width : height$ of the image.newline
Find a value $k$ such that $area = kx times ky$:
beginalign*
area &= (k)x times (k)y\
area &= k^2times (xy)\ % Step 1 (in the preamble) stores x*y.
fracareaxy &= k^2\ % Step 2 (in the preamble) stores area/(x*y)
sqrtfracareaxy &= k\% Step 3 (in the preamble) stores sqrt((area/(x*y)))
endalign*
Now, multiply $k$ by the our ratio given, $x : y$. % Steps 4 and 5 (in the preamble).
[kx : ky]
Which yields to $area = kx times ky$. hfill $blacksquare$
enddocument
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:46
I have updated the answer, check it out.
â M. Al Jumaily
Aug 20 at 5:17
1
You say that my desire is not achievable, but if you know an area A = W x H and an aspect ratio R = W / H, you can definitively find unique values for width W and height H, which is what I'm asking.
â mmj
Aug 20 at 22:06
Did you read all the post? If you elimanate the real values then sure, you can find a ratio assuming that W and H are not at the lowest ratio form, like W=2 and H=8... which you can have a reduced ratio of 1:4.... Now, if your ratio is 4:5, you cannot reduce it further because it's in the lowest form already... if you want you can enter the real values and divide it by 2 to obtain 2:2.5 but then you entered the real values where there are infinite solutions. You can divide by 2 or 3 or 4 or even 10000000^10000.... all are valid decimal ratios.
â M. Al Jumaily
Aug 20 at 22:06
1
I think there is a misunderstanding. The aspect ratio of an image is always a rational number. You cannot "reduce" the ratio because width x height must be equal to a given and arbitrary number, the area. My previous comment explain the simple math behind the question.
â mmj
Aug 20 at 22:17
 |Â
show 4 more comments
up vote
3
down vote
Here is an MCVE that fulfills your requirements provided th. I have also added commented the code and added a full explanation with regards to the logic of the program.
Sample output:
Now the explanation:
The code!:
documentclass[12pt]article
usepackagegraphicx, color
usepackage[margin=0.5in]geometry
usepackagecalculator % Very important package. Provides
% basic mathematical operations like
% addition, subtracting, multiplying
% dividing, rounding, truncating, and
% finding the GCD (greatest common divisor).
usepackagecaption, amsmath, amssymb
makeatletter
newcommand*getlength[1]strip@pt#1
makeatother
% For the area, and ratio (width:height) = (xRatio:yRatio)
newlengthareaGiven
newlengthxRatio
newlengthyRatio
% Accepts 4 argments: area, width ratio, height ratio, and name of image (respectively).
newcommand*adjustImage[4]%
setlengthareaGiven#1 cm
setlengthxRatio#2 cm
setlengthyRatio#3 cm
noindent Given information~~~~~~~~~~~: textbfarea = #1cm,
textbfratio $(width:height) = #2:#3$.
% Convert the unit from pt to cm. Note, 1pt = 0.0352778cm.
% If you really care about exact numbers, 1.0000008pt = 0.035277806cm.
% If inches is the unit to focus on, then change 0.0352778 to 0.0138889.
MULTIPLYgetlengthareaGiven0.0352778areaInCm
MULTIPLYgetlengthxRatio0.0352778xRatioInCm
MULTIPLYgetlengthyRatio0.0352778yRatioInCm
noindent Converting from pt to cm : textbfarea = areaInCm cm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% Keep in mind that there will be rounding errors. The answer
% we will obtain is a decimal answer. Since pixels are atomic, we need to
% truncate (or round) the decimal values to secure a whole number.
% I used the TRUNCATE command, you can comment the next three line and
% uncomment the ROUND commands if you want to round.
TRUNCATE[0]areaInCmareaInCm
TRUNCATE[0]xRatioInCmxRatioInCm
TRUNCATE[0]yRatioInCmyRatioInCm
% OR use round instead. It is better for images with areas 100+.
% ROUND[0]areaInCmareaInCm
% ROUND[0]xRatioInCmxRatioInCm
% ROUND[0]yRatioInCmyRatioInCm
noindent After truncating~~~~~~~~~~~~~: textbfarea = areaInCm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% The following are the steps of find the result mathematically.
% This is explained in details at the end of the docmument.
MULTIPLYxRatioInCmyRatioInCmk % 1) finds (a*b) in ak*bk = area.
DIVIDEareaInCmkk % 2) finds (area/(a*b)) in k^2 = (area/(a*b)).
SQUAREROOTkkFinal % 3) finds of k in k = sqrt((area/(a*b))).
MULTIPLYxRatioInCmkFinalx % 4) multiplies the x-ratio by k.
MULTIPLYyRatioInCmkFinaly % 5) multiplies the y-ratio by k.
noindent textbfFinal dimensions are~~~:
textbfwidth = x cm, textbfheight = y cm.
begincenter
includegraphics[width = x cm, height = y cm]#4 % 6*3 cm
captionoffigure
textbfarea = #1cm, textbfratio
$(width:height) = #2:#3$ $longrightarrow$
textbfwidth = x cm, textbfheight = y cm.
endcenter
begindocument
noindent
textcolorredtextbfExample A:newline
adjustImage1821example-image-a % area = 18cm, ratio (width:height) = 2:1
textcolorredtextbfExample B:newline
adjustImage1823example-image-b % area = 18cm, ratio (width:height) = 2:3
textcolorredtextbfExample C:newline
adjustImage3221example-image-c % area = 32cm, ratio (width:height) = 2:1
% Maximum area is 575 units!
% adjustImage57521TestImage.png % area = 575cm, ratio (width:height) = 2:1
newpage
newgeometrymargin=1in
% Here is the explanation of the logic.
noindenttextbfExplaining the logic with an example:newline
The logic is a simple mathematical manipulation.newline
First, we need our three variables,
the total area we will call $area$ and the ratio $x : y$.newlinenewline
Let $area = 18$ and the ratio $x : y = 2 : 1$.newline
We know that $x times y = area$ or in other words, $2x times y = 18$.newline
For simplicity, let's only use one variable, $k$. Substitute $k$ newline
in our previous equation for both $x$ and $y$, $2k times k = 18$.newline
Solve for $k$:
beginalign*
2k times k &= 18\
2k^2 &= 18\
k^2 &= 9\
k &= 3
endalign*
Now, we multiply $k = 3$ in our original ratio $x : y = 2 : 1$.newline
Hence, our desired ratio is :
beginalign*
x : y &= 2(k) : 1(k)\
x : y &= 2(3) : 1(3)\
x : y &= 6 : 3\
endalign*bigskip
% Formal definition.
noindenttextbfFormal definition:newline
Let $area$ represent the total area of the image and the ratio $x : y$ respectively
represent the $width : height$ of the image.newline
Find a value $k$ such that $area = kx times ky$:
beginalign*
area &= (k)x times (k)y\
area &= k^2times (xy)\ % Step 1 (in the preamble) stores x*y.
fracareaxy &= k^2\ % Step 2 (in the preamble) stores area/(x*y)
sqrtfracareaxy &= k\% Step 3 (in the preamble) stores sqrt((area/(x*y)))
endalign*
Now, multiply $k$ by the our ratio given, $x : y$. % Steps 4 and 5 (in the preamble).
[kx : ky]
Which yields to $area = kx times ky$. hfill $blacksquare$
enddocument
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:46
I have updated the answer, check it out.
â M. Al Jumaily
Aug 20 at 5:17
1
You say that my desire is not achievable, but if you know an area A = W x H and an aspect ratio R = W / H, you can definitively find unique values for width W and height H, which is what I'm asking.
â mmj
Aug 20 at 22:06
Did you read all the post? If you elimanate the real values then sure, you can find a ratio assuming that W and H are not at the lowest ratio form, like W=2 and H=8... which you can have a reduced ratio of 1:4.... Now, if your ratio is 4:5, you cannot reduce it further because it's in the lowest form already... if you want you can enter the real values and divide it by 2 to obtain 2:2.5 but then you entered the real values where there are infinite solutions. You can divide by 2 or 3 or 4 or even 10000000^10000.... all are valid decimal ratios.
â M. Al Jumaily
Aug 20 at 22:06
1
I think there is a misunderstanding. The aspect ratio of an image is always a rational number. You cannot "reduce" the ratio because width x height must be equal to a given and arbitrary number, the area. My previous comment explain the simple math behind the question.
â mmj
Aug 20 at 22:17
 |Â
show 4 more comments
up vote
3
down vote
up vote
3
down vote
Here is an MCVE that fulfills your requirements provided th. I have also added commented the code and added a full explanation with regards to the logic of the program.
Sample output:
Now the explanation:
The code!:
documentclass[12pt]article
usepackagegraphicx, color
usepackage[margin=0.5in]geometry
usepackagecalculator % Very important package. Provides
% basic mathematical operations like
% addition, subtracting, multiplying
% dividing, rounding, truncating, and
% finding the GCD (greatest common divisor).
usepackagecaption, amsmath, amssymb
makeatletter
newcommand*getlength[1]strip@pt#1
makeatother
% For the area, and ratio (width:height) = (xRatio:yRatio)
newlengthareaGiven
newlengthxRatio
newlengthyRatio
% Accepts 4 argments: area, width ratio, height ratio, and name of image (respectively).
newcommand*adjustImage[4]%
setlengthareaGiven#1 cm
setlengthxRatio#2 cm
setlengthyRatio#3 cm
noindent Given information~~~~~~~~~~~: textbfarea = #1cm,
textbfratio $(width:height) = #2:#3$.
% Convert the unit from pt to cm. Note, 1pt = 0.0352778cm.
% If you really care about exact numbers, 1.0000008pt = 0.035277806cm.
% If inches is the unit to focus on, then change 0.0352778 to 0.0138889.
MULTIPLYgetlengthareaGiven0.0352778areaInCm
MULTIPLYgetlengthxRatio0.0352778xRatioInCm
MULTIPLYgetlengthyRatio0.0352778yRatioInCm
noindent Converting from pt to cm : textbfarea = areaInCm cm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% Keep in mind that there will be rounding errors. The answer
% we will obtain is a decimal answer. Since pixels are atomic, we need to
% truncate (or round) the decimal values to secure a whole number.
% I used the TRUNCATE command, you can comment the next three line and
% uncomment the ROUND commands if you want to round.
TRUNCATE[0]areaInCmareaInCm
TRUNCATE[0]xRatioInCmxRatioInCm
TRUNCATE[0]yRatioInCmyRatioInCm
% OR use round instead. It is better for images with areas 100+.
% ROUND[0]areaInCmareaInCm
% ROUND[0]xRatioInCmxRatioInCm
% ROUND[0]yRatioInCmyRatioInCm
noindent After truncating~~~~~~~~~~~~~: textbfarea = areaInCm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% The following are the steps of find the result mathematically.
% This is explained in details at the end of the docmument.
MULTIPLYxRatioInCmyRatioInCmk % 1) finds (a*b) in ak*bk = area.
DIVIDEareaInCmkk % 2) finds (area/(a*b)) in k^2 = (area/(a*b)).
SQUAREROOTkkFinal % 3) finds of k in k = sqrt((area/(a*b))).
MULTIPLYxRatioInCmkFinalx % 4) multiplies the x-ratio by k.
MULTIPLYyRatioInCmkFinaly % 5) multiplies the y-ratio by k.
noindent textbfFinal dimensions are~~~:
textbfwidth = x cm, textbfheight = y cm.
begincenter
includegraphics[width = x cm, height = y cm]#4 % 6*3 cm
captionoffigure
textbfarea = #1cm, textbfratio
$(width:height) = #2:#3$ $longrightarrow$
textbfwidth = x cm, textbfheight = y cm.
endcenter
begindocument
noindent
textcolorredtextbfExample A:newline
adjustImage1821example-image-a % area = 18cm, ratio (width:height) = 2:1
textcolorredtextbfExample B:newline
adjustImage1823example-image-b % area = 18cm, ratio (width:height) = 2:3
textcolorredtextbfExample C:newline
adjustImage3221example-image-c % area = 32cm, ratio (width:height) = 2:1
% Maximum area is 575 units!
% adjustImage57521TestImage.png % area = 575cm, ratio (width:height) = 2:1
newpage
newgeometrymargin=1in
% Here is the explanation of the logic.
noindenttextbfExplaining the logic with an example:newline
The logic is a simple mathematical manipulation.newline
First, we need our three variables,
the total area we will call $area$ and the ratio $x : y$.newlinenewline
Let $area = 18$ and the ratio $x : y = 2 : 1$.newline
We know that $x times y = area$ or in other words, $2x times y = 18$.newline
For simplicity, let's only use one variable, $k$. Substitute $k$ newline
in our previous equation for both $x$ and $y$, $2k times k = 18$.newline
Solve for $k$:
beginalign*
2k times k &= 18\
2k^2 &= 18\
k^2 &= 9\
k &= 3
endalign*
Now, we multiply $k = 3$ in our original ratio $x : y = 2 : 1$.newline
Hence, our desired ratio is :
beginalign*
x : y &= 2(k) : 1(k)\
x : y &= 2(3) : 1(3)\
x : y &= 6 : 3\
endalign*bigskip
% Formal definition.
noindenttextbfFormal definition:newline
Let $area$ represent the total area of the image and the ratio $x : y$ respectively
represent the $width : height$ of the image.newline
Find a value $k$ such that $area = kx times ky$:
beginalign*
area &= (k)x times (k)y\
area &= k^2times (xy)\ % Step 1 (in the preamble) stores x*y.
fracareaxy &= k^2\ % Step 2 (in the preamble) stores area/(x*y)
sqrtfracareaxy &= k\% Step 3 (in the preamble) stores sqrt((area/(x*y)))
endalign*
Now, multiply $k$ by the our ratio given, $x : y$. % Steps 4 and 5 (in the preamble).
[kx : ky]
Which yields to $area = kx times ky$. hfill $blacksquare$
enddocument
Here is an MCVE that fulfills your requirements provided th. I have also added commented the code and added a full explanation with regards to the logic of the program.
Sample output:
Now the explanation:
The code!:
documentclass[12pt]article
usepackagegraphicx, color
usepackage[margin=0.5in]geometry
usepackagecalculator % Very important package. Provides
% basic mathematical operations like
% addition, subtracting, multiplying
% dividing, rounding, truncating, and
% finding the GCD (greatest common divisor).
usepackagecaption, amsmath, amssymb
makeatletter
newcommand*getlength[1]strip@pt#1
makeatother
% For the area, and ratio (width:height) = (xRatio:yRatio)
newlengthareaGiven
newlengthxRatio
newlengthyRatio
% Accepts 4 argments: area, width ratio, height ratio, and name of image (respectively).
newcommand*adjustImage[4]%
setlengthareaGiven#1 cm
setlengthxRatio#2 cm
setlengthyRatio#3 cm
noindent Given information~~~~~~~~~~~: textbfarea = #1cm,
textbfratio $(width:height) = #2:#3$.
% Convert the unit from pt to cm. Note, 1pt = 0.0352778cm.
% If you really care about exact numbers, 1.0000008pt = 0.035277806cm.
% If inches is the unit to focus on, then change 0.0352778 to 0.0138889.
MULTIPLYgetlengthareaGiven0.0352778areaInCm
MULTIPLYgetlengthxRatio0.0352778xRatioInCm
MULTIPLYgetlengthyRatio0.0352778yRatioInCm
noindent Converting from pt to cm : textbfarea = areaInCm cm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% Keep in mind that there will be rounding errors. The answer
% we will obtain is a decimal answer. Since pixels are atomic, we need to
% truncate (or round) the decimal values to secure a whole number.
% I used the TRUNCATE command, you can comment the next three line and
% uncomment the ROUND commands if you want to round.
TRUNCATE[0]areaInCmareaInCm
TRUNCATE[0]xRatioInCmxRatioInCm
TRUNCATE[0]yRatioInCmyRatioInCm
% OR use round instead. It is better for images with areas 100+.
% ROUND[0]areaInCmareaInCm
% ROUND[0]xRatioInCmxRatioInCm
% ROUND[0]yRatioInCmyRatioInCm
noindent After truncating~~~~~~~~~~~~~: textbfarea = areaInCm,
textbfratio $(width:height) = xRatioInCm cm:yRatioInCm cm$.
% The following are the steps of find the result mathematically.
% This is explained in details at the end of the docmument.
MULTIPLYxRatioInCmyRatioInCmk % 1) finds (a*b) in ak*bk = area.
DIVIDEareaInCmkk % 2) finds (area/(a*b)) in k^2 = (area/(a*b)).
SQUAREROOTkkFinal % 3) finds of k in k = sqrt((area/(a*b))).
MULTIPLYxRatioInCmkFinalx % 4) multiplies the x-ratio by k.
MULTIPLYyRatioInCmkFinaly % 5) multiplies the y-ratio by k.
noindent textbfFinal dimensions are~~~:
textbfwidth = x cm, textbfheight = y cm.
begincenter
includegraphics[width = x cm, height = y cm]#4 % 6*3 cm
captionoffigure
textbfarea = #1cm, textbfratio
$(width:height) = #2:#3$ $longrightarrow$
textbfwidth = x cm, textbfheight = y cm.
endcenter
begindocument
noindent
textcolorredtextbfExample A:newline
adjustImage1821example-image-a % area = 18cm, ratio (width:height) = 2:1
textcolorredtextbfExample B:newline
adjustImage1823example-image-b % area = 18cm, ratio (width:height) = 2:3
textcolorredtextbfExample C:newline
adjustImage3221example-image-c % area = 32cm, ratio (width:height) = 2:1
% Maximum area is 575 units!
% adjustImage57521TestImage.png % area = 575cm, ratio (width:height) = 2:1
newpage
newgeometrymargin=1in
% Here is the explanation of the logic.
noindenttextbfExplaining the logic with an example:newline
The logic is a simple mathematical manipulation.newline
First, we need our three variables,
the total area we will call $area$ and the ratio $x : y$.newlinenewline
Let $area = 18$ and the ratio $x : y = 2 : 1$.newline
We know that $x times y = area$ or in other words, $2x times y = 18$.newline
For simplicity, let's only use one variable, $k$. Substitute $k$ newline
in our previous equation for both $x$ and $y$, $2k times k = 18$.newline
Solve for $k$:
beginalign*
2k times k &= 18\
2k^2 &= 18\
k^2 &= 9\
k &= 3
endalign*
Now, we multiply $k = 3$ in our original ratio $x : y = 2 : 1$.newline
Hence, our desired ratio is :
beginalign*
x : y &= 2(k) : 1(k)\
x : y &= 2(3) : 1(3)\
x : y &= 6 : 3\
endalign*bigskip
% Formal definition.
noindenttextbfFormal definition:newline
Let $area$ represent the total area of the image and the ratio $x : y$ respectively
represent the $width : height$ of the image.newline
Find a value $k$ such that $area = kx times ky$:
beginalign*
area &= (k)x times (k)y\
area &= k^2times (xy)\ % Step 1 (in the preamble) stores x*y.
fracareaxy &= k^2\ % Step 2 (in the preamble) stores area/(x*y)
sqrtfracareaxy &= k\% Step 3 (in the preamble) stores sqrt((area/(x*y)))
endalign*
Now, multiply $k$ by the our ratio given, $x : y$. % Steps 4 and 5 (in the preamble).
[kx : ky]
Which yields to $area = kx times ky$. hfill $blacksquare$
enddocument
edited Aug 23 at 1:16
answered Aug 19 at 11:23
M. Al Jumaily
3636
3636
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:46
I have updated the answer, check it out.
â M. Al Jumaily
Aug 20 at 5:17
1
You say that my desire is not achievable, but if you know an area A = W x H and an aspect ratio R = W / H, you can definitively find unique values for width W and height H, which is what I'm asking.
â mmj
Aug 20 at 22:06
Did you read all the post? If you elimanate the real values then sure, you can find a ratio assuming that W and H are not at the lowest ratio form, like W=2 and H=8... which you can have a reduced ratio of 1:4.... Now, if your ratio is 4:5, you cannot reduce it further because it's in the lowest form already... if you want you can enter the real values and divide it by 2 to obtain 2:2.5 but then you entered the real values where there are infinite solutions. You can divide by 2 or 3 or 4 or even 10000000^10000.... all are valid decimal ratios.
â M. Al Jumaily
Aug 20 at 22:06
1
I think there is a misunderstanding. The aspect ratio of an image is always a rational number. You cannot "reduce" the ratio because width x height must be equal to a given and arbitrary number, the area. My previous comment explain the simple math behind the question.
â mmj
Aug 20 at 22:17
 |Â
show 4 more comments
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:46
I have updated the answer, check it out.
â M. Al Jumaily
Aug 20 at 5:17
1
You say that my desire is not achievable, but if you know an area A = W x H and an aspect ratio R = W / H, you can definitively find unique values for width W and height H, which is what I'm asking.
â mmj
Aug 20 at 22:06
Did you read all the post? If you elimanate the real values then sure, you can find a ratio assuming that W and H are not at the lowest ratio form, like W=2 and H=8... which you can have a reduced ratio of 1:4.... Now, if your ratio is 4:5, you cannot reduce it further because it's in the lowest form already... if you want you can enter the real values and divide it by 2 to obtain 2:2.5 but then you entered the real values where there are infinite solutions. You can divide by 2 or 3 or 4 or even 10000000^10000.... all are valid decimal ratios.
â M. Al Jumaily
Aug 20 at 22:06
1
I think there is a misunderstanding. The aspect ratio of an image is always a rational number. You cannot "reduce" the ratio because width x height must be equal to a given and arbitrary number, the area. My previous comment explain the simple math behind the question.
â mmj
Aug 20 at 22:17
1
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:46
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:46
I have updated the answer, check it out.
â M. Al Jumaily
Aug 20 at 5:17
I have updated the answer, check it out.
â M. Al Jumaily
Aug 20 at 5:17
1
1
You say that my desire is not achievable, but if you know an area A = W x H and an aspect ratio R = W / H, you can definitively find unique values for width W and height H, which is what I'm asking.
â mmj
Aug 20 at 22:06
You say that my desire is not achievable, but if you know an area A = W x H and an aspect ratio R = W / H, you can definitively find unique values for width W and height H, which is what I'm asking.
â mmj
Aug 20 at 22:06
Did you read all the post? If you elimanate the real values then sure, you can find a ratio assuming that W and H are not at the lowest ratio form, like W=2 and H=8... which you can have a reduced ratio of 1:4.... Now, if your ratio is 4:5, you cannot reduce it further because it's in the lowest form already... if you want you can enter the real values and divide it by 2 to obtain 2:2.5 but then you entered the real values where there are infinite solutions. You can divide by 2 or 3 or 4 or even 10000000^10000.... all are valid decimal ratios.
â M. Al Jumaily
Aug 20 at 22:06
Did you read all the post? If you elimanate the real values then sure, you can find a ratio assuming that W and H are not at the lowest ratio form, like W=2 and H=8... which you can have a reduced ratio of 1:4.... Now, if your ratio is 4:5, you cannot reduce it further because it's in the lowest form already... if you want you can enter the real values and divide it by 2 to obtain 2:2.5 but then you entered the real values where there are infinite solutions. You can divide by 2 or 3 or 4 or even 10000000^10000.... all are valid decimal ratios.
â M. Al Jumaily
Aug 20 at 22:06
1
1
I think there is a misunderstanding. The aspect ratio of an image is always a rational number. You cannot "reduce" the ratio because width x height must be equal to a given and arbitrary number, the area. My previous comment explain the simple math behind the question.
â mmj
Aug 20 at 22:17
I think there is a misunderstanding. The aspect ratio of an image is always a rational number. You cannot "reduce" the ratio because width x height must be equal to a given and arbitrary number, the area. My previous comment explain the simple math behind the question.
â mmj
Aug 20 at 22:17
 |Â
show 4 more comments
up vote
2
down vote
documentclass[12pt]article
usepackagegraphicx
begindocument
beginfigure% only needed if you want captions
includegraphics[width=linewidth]example-image-a
bigskip
makebox[linewidth]% only needed if the textwidth is smaller than the images
includegraphics[width=6cm,height=3cm,keepaspectratio=false]example-image-b
includegraphics[width=3.464cm,height=5.196cm,keepaspectratio=false]example-image-b
includegraphics[width=8cm,height=4cm,keepaspectratio=false]example-image-b%
endfigure
enddocument
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:45
1
then use[width=...,height=...,keepaspectratio=false]image
. see edited answer
â Herbert
Aug 19 at 17:23
2
I don't want to change the aspect ratio of images, I want a LaTeX command which use the aspect ratio R = W / H of image AND an area parameter A chosen by me, to calculate the width W and height H of image so that W x H = A and W / H = R.
â mmj
Aug 20 at 22:01
add a comment |Â
up vote
2
down vote
documentclass[12pt]article
usepackagegraphicx
begindocument
beginfigure% only needed if you want captions
includegraphics[width=linewidth]example-image-a
bigskip
makebox[linewidth]% only needed if the textwidth is smaller than the images
includegraphics[width=6cm,height=3cm,keepaspectratio=false]example-image-b
includegraphics[width=3.464cm,height=5.196cm,keepaspectratio=false]example-image-b
includegraphics[width=8cm,height=4cm,keepaspectratio=false]example-image-b%
endfigure
enddocument
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:45
1
then use[width=...,height=...,keepaspectratio=false]image
. see edited answer
â Herbert
Aug 19 at 17:23
2
I don't want to change the aspect ratio of images, I want a LaTeX command which use the aspect ratio R = W / H of image AND an area parameter A chosen by me, to calculate the width W and height H of image so that W x H = A and W / H = R.
â mmj
Aug 20 at 22:01
add a comment |Â
up vote
2
down vote
up vote
2
down vote
documentclass[12pt]article
usepackagegraphicx
begindocument
beginfigure% only needed if you want captions
includegraphics[width=linewidth]example-image-a
bigskip
makebox[linewidth]% only needed if the textwidth is smaller than the images
includegraphics[width=6cm,height=3cm,keepaspectratio=false]example-image-b
includegraphics[width=3.464cm,height=5.196cm,keepaspectratio=false]example-image-b
includegraphics[width=8cm,height=4cm,keepaspectratio=false]example-image-b%
endfigure
enddocument
documentclass[12pt]article
usepackagegraphicx
begindocument
beginfigure% only needed if you want captions
includegraphics[width=linewidth]example-image-a
bigskip
makebox[linewidth]% only needed if the textwidth is smaller than the images
includegraphics[width=6cm,height=3cm,keepaspectratio=false]example-image-b
includegraphics[width=3.464cm,height=5.196cm,keepaspectratio=false]example-image-b
includegraphics[width=8cm,height=4cm,keepaspectratio=false]example-image-b%
endfigure
enddocument
edited Aug 19 at 17:22
answered Aug 19 at 11:32
Herbert
261k21395705
261k21395705
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:45
1
then use[width=...,height=...,keepaspectratio=false]image
. see edited answer
â Herbert
Aug 19 at 17:23
2
I don't want to change the aspect ratio of images, I want a LaTeX command which use the aspect ratio R = W / H of image AND an area parameter A chosen by me, to calculate the width W and height H of image so that W x H = A and W / H = R.
â mmj
Aug 20 at 22:01
add a comment |Â
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:45
1
then use[width=...,height=...,keepaspectratio=false]image
. see edited answer
â Herbert
Aug 19 at 17:23
2
I don't want to change the aspect ratio of images, I want a LaTeX command which use the aspect ratio R = W / H of image AND an area parameter A chosen by me, to calculate the width W and height H of image so that W x H = A and W / H = R.
â mmj
Aug 20 at 22:01
1
1
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:45
I don't understand your answer, maybe my question wasn't clear enough, please see the update.
â mmj
Aug 19 at 14:45
1
1
then use
[width=...,height=...,keepaspectratio=false]image
. see edited answerâ Herbert
Aug 19 at 17:23
then use
[width=...,height=...,keepaspectratio=false]image
. see edited answerâ Herbert
Aug 19 at 17:23
2
2
I don't want to change the aspect ratio of images, I want a LaTeX command which use the aspect ratio R = W / H of image AND an area parameter A chosen by me, to calculate the width W and height H of image so that W x H = A and W / H = R.
â mmj
Aug 20 at 22:01
I don't want to change the aspect ratio of images, I want a LaTeX command which use the aspect ratio R = W / H of image AND an area parameter A chosen by me, to calculate the width W and height H of image so that W x H = A and W / H = R.
â mmj
Aug 20 at 22:01
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f446660%2fsize-image-by-area%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Do your images have the same area before you include them?
â samcarter
Aug 19 at 11:17
@samcarter No, of course.
â mmj
Aug 19 at 14:14