Follow-up Comment #3, bug #68781 (group groff): The parameters you suggest are exactly the ones which are used for 'pdf: import'. I must finish the code sometime!
'pdf: inline' is an alternative to 'pdf: pdfpic' but sits the image on the
baseline instead of under it.
The extended arguments "llx lly urx ury width [height]" for 'ps: import are
rather strange! You might assume ll/ur are describing a rectangle on the page,
or perhaps a cropbox of the image, neither. .PSPIC populates them with the
values from psbb, i.e. the eps bounding box, which grops knows already when it
reads the eps! What happens if you fiddle the numbers. Assuming llx,lly is 0,0
and the width is 72000 (1 inch), if you halve urx the image grows to 2i. I
don't understand this API, I don't find it particularly useful. This is
probably why I never completed 'pdf: import'. Much more useful would be either
a 4 param version describing a rectangle on the groff page in which the image
is fitted (so you don't need to use tricks like .vs 0/.sp | to include an
image exactly where you want it), or a 2 param version which behaves like
'pdf: inline' now, one difference is using -f flag which will deform the image
to fit width/height exactly.
I have attached a ms document plus pdf and eps so you can play with the
numbers and hopefully explain the idea behind the API.
> ...where encoded-file-name is the file name of concern with all code points
> in the range U+0021 (!) to U+007E (~), except for U+005C (\), encoded as
> themselves. Any other code points in the file name are to be encoded in
> `\[u00nn]` syntax where nn is the code point in hexadecimal.
If you edit gropdf.pl from this:-
elsif (lc($xprm[1]) eq 'pdfpic')
{
my $fil=$xprm[2];
to this:-
elsif (lc($xprm[1]) eq 'pdfpic')
{
my $fil=URIName($xprm[2]);
the attached ms document will embed the 'my Ж.pdf' file (don't forget the
-Kutf8).
> For example, inlining a file named "my cat.jpg", a "full HD" image, would be
> done as follows.
\X'pdf: inline my\[u0020]cat.jpg 0 1080 1920 0 1920'
It's difficult to comment because you have not specified how these parameters
interact, so I am assuming you mean exactly the same as used in 'ps: import'.
This is what grops.1 says:-
\X'ps: import file llx lly urx ury width [height]'
Import a PostScript graphic from file. The arguments llx, lly,
urx, and ury give
the bounding box of the graphic in the default PostScript
coordinate system. They
should all be integers: llx and lly are the x and y coordinates of
the lower left
corner of the graphic; urx and ury are the x and y coordinates
of the upper right
corner of the graphic; width and height are integers that give the
desired width and
height in groff basic units of the graphic.
The graphic is scaled so that it has this width and height and
translated so that
the lower left corner of the graphic is located at the position
associated with \X
command. If the height argument is omitted it is scaled
uniformly in the x and
y axes so that it has the specified width.
The contents of the \X command are not interpreted by troff, so
vertical space for
the graphic is not automatically added, and the width and height
arguments are not
allowed to have attached scaling indicators.
If the PostScript file complies with the Adobe Document
Structuring Conventions and
contains a %%BoundingBox comment, then the bounding box can be
automatically ex‐
tracted from within groff input by using the psbb request.
So the box parameters are the BoundingBox of the graphic in millipoints and
coordinate system is 0,0 is bottom left (not top left - groff coordinates). I
suppose this information is in case there is no %%BoundingBox in the eps file,
can't happen with pdf.
None of the parameters seem to affect the position of the image on the page -
"the lower left corner of the graphic is located at the position associated
with the \X command" - i.e. inline with the text. .PSPIC on the otherhand
places top left corner on the baseline.
Going back to your example - running these paameters with 'ps: import' -
assuming coordinate system 0,0 is corrected and width / height values
converted to millipoints this probably is not achieving what you expect. The
box values are in pixels, width and height are physical distances on the
page.
What are the advantages of this API over the one people are used to using with
'pdf: pdfpic'? If you can give me a rational reason why this is an improvement
I would consider it and finish 'pdf: import' with the same API as you want.
(file #59104, file #59105, file #59106)
_______________________________________________________
Additional Item Attachment:
Name: D.ms Size: 229B
<https://file.savannah.gnu.org/file/D.ms?file_id=59104>
Name: D.eps Size: 17KiB
<https://file.savannah.gnu.org/file/D.eps?file_id=59105>
Name: my Ж.pdf Size: 3.4KiB
<https://file.savannah.gnu.org/file/my+%D0%96.pdf?file_id=59106>
AGPL NOTICE
These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-008698919f826f0fb06bcafffba4902404c2a7d0.tar.gz
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68781>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
