Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add png, pdf and jpeg image support to the latex backend #1297

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Octachron
Copy link
Member

@Octachron Octachron commented Jan 28, 2025

This small PR adds support for images to the latex backed for png, pdf, and jpeg internal assets.

As a side-note, I am slightly surprised that there is no support for width information on the media tags since both image and video are hard to place properly without fixing their size.

@panglesd
Copy link
Collaborator

Thanks a lot for the PR!

Yes, I agree that it is the first thing we should do for images. (#1286)

The main problem is deciding the syntax. There is no existing syntax for attributes so we have to create something new. I can't find issues with the discussion, it must have happened elsewhere, but we could not find a consensus on the syntax and decided to start without it (in the worst case, images themselves can be resized I think).

I'll restart the discussion in #1286 with some propositions soon.

Copy link
Collaborator

@panglesd panglesd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

I'm curious about the choice of extensions: shouldn't jpg, and capitalized extensions, be allowed as well?
I suspect the list of supported format depends on the latex implementation.

Maybe the list taken from here could be be a valid choice:

.pdf,.png,.jpg,.mps,.jpeg,.jbig2,.jb2,.PDF,.PNG,.JPG,.JPEG,.JBIG2,.JB2

Also I think it needs ocamlformatting! (maybe we should use this action?)

src/latex/generator.ml Outdated Show resolved Hide resolved
@dbuenzli
Copy link
Contributor

both image and video are hard to place properly without fixing their size.

I don't have this in my head but I think this is no longer the case with the CSS object-fit property. If we want to have responsive web pages it's actually better if we avoid people specifying explicit absolute image sizes (it's also brittle if you change the image aspect ratio).

@panglesd
Copy link
Collaborator

I'm not sure to understand! object-fit decides how images are placed in their bounding box.

But if the user can't decide the dimension of the bounding box, it does not help much?

Also, it is hard for odoc to decide on a "good size for all": eg vg has small images, but in other contexts a big image makes sense.

Am I missing something?

@dbuenzli
Copy link
Contributor

IIRC for responsive images you basically want users to define one dimension with a relative unit. If it's horizontal it should be a percentage of the measure. If it's vertical a multiple of the leading, capped so that it doesn't overflow the measure. That's for running text but if you have a table for example then your box may already have constraints at which point (again IIRC) object-fit comes handy.

@dbuenzli
Copy link
Contributor

Basically user should work with the assumption that the css has:

img, picture, video, canvas, svg { max-width: 100%; display: block }

@Octachron
Copy link
Member Author

I have added support for all image formats supported by pdftex by default.

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

Successfully merging this pull request may close these issues.

3 participants