Skip to content

Comments

Remove dependency on exiftool#82

Merged
TheOnlyWayUp merged 9 commits intomasterfrom
feature/#80-dockerfile
Oct 30, 2025
Merged

Remove dependency on exiftool#82
TheOnlyWayUp merged 9 commits intomasterfrom
feature/#80-dockerfile

Conversation

@TheOnlyWayUp
Copy link
Owner

Fixes #80

Metadata is embedded via HTML <meta> tags, which Weasyprint parses natively.

from weasyprint import HTML
s = """<head>
    <title>...</title>
    <meta name=author content="theonlywayup">  # All the metadata is embedded like this
    <meta name=custom content="metadata">
  </head>
  """
h = HTML(string=s)
doc = h.render()

For an alternative method, the metadata can be viewed and edited through the doc.metadata attr, doc is also also available during HTML.write_pdf (through the finisher function parameter). Calling doc.metadata.__dict__ gives us,

{
    'title': '...',
    'authors': ['theonlywayup'],
    'description': '',
    'keywords': [],
    'generator': '',
    'created': None,
    'modified': None,
    'attachments': [],
    'lang': None,
    'custom': {'custom': 'metadata'}
}

The metadata is passed while rendering the HTML Template, so adding metadata tags is the most natural solution.

Copy link
Collaborator

@AaronBenDaniel AaronBenDaniel left a comment

Choose a reason for hiding this comment

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

Two things that would be fine if left alone, but I think they should be addressed.

Also, at some point, though not in this PR, #36 came back. This is because of the tags used in /src/api/src/create_book/generators/pdf/book.html.

image

@TheOnlyWayUp
Copy link
Owner Author

Also, at some point, though not in this PR, #36 came back.

This is intentional behaviour, the fix for #36 elevated just the ToC to h1, the copyright notice was still a dropdown containing the story title. Iirc

@TheOnlyWayUp TheOnlyWayUp merged commit cc9ac60 into master Oct 30, 2025
@AaronBenDaniel
Copy link
Collaborator

AaronBenDaniel commented Oct 30, 2025

This did not happen when I tested it on October 28, but I just built from master, and the image downloaded the botocore package when run. I don't know much about uv, but does it always try to use the most up-to-date packages? I see pyproject.toml uses >=, which implies that it does. We should consider forcing uv to use only specific versions of packages, so the image will only need to use the packages it downloaded during the build process.

AaronBenDaniel added a commit that referenced this pull request Oct 30, 2025
@AaronBenDaniel
Copy link
Collaborator

This did not happen when I tested it on October 28, but I just built from master, and the image downloaded the botocore package when run. I don't know much about uv, but does it always try to use the most up-to-date packages? I see pyproject.toml uses >=, which implies that it does. We should consider forcing uv to use only specific versions of packages, so the image will only need to use the packages it downloaded during the build process.

This is not why it's downloading new packages. The .dockerignore file is not working as expected, and uv.lock is still getting copied in and overwriting the one uv sync generates. The uv.lock in the git repo is out of date, which is causing the problem.

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.

Image fails to build

2 participants