xkcd: comic is drawn too small to fill the screen
Los mantenedores suelen responder en 1 día
Ya se ha fusionado un pull request relacionado.
- #287 de @txoof-bot — fusionado
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- Medio día
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- python
- Área
- embedded-iot
Línea de trabajo
Start in src/paperpi/plugins/xkcd_comic/init.py, in the draw function, to see how the enlarge setting decides whether a comic smaller than its block is scaled, and how max_width and max_height skip large comics. The default is a maintainer decision, so confirm it with txoof before changing it. Done when comics fill their block on the 9.7", 7.5" and 5.65" sample images, the enlarge help text explains the behavior, and the sample images are regenerated.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Seen in the web interface demo (2026-10-10, virtual screen 1200x825).
Problem: the comic is drawn much smaller than the space it has, so it doesn't fill the screen well and is likely hard to read on the e-paper screen.
Likely cause: the plugin setting enlarge is off by default. With it off, a comic smaller than its block is drawn at its own pixel size and never scaled up (src/paperpi/plugins/xkcd_comic/__init__.py, draw). Most xkcd comics are a few hundred pixels wide, while the 9.7" screen is 1200x825, so most comics come out small.
To decide (ask txoof first):
- Should the comic be scaled up to fill its block by default (
enlarge = true), or only up to a limit (for example at most 2x, so pixel art doesn't get too blocky)? - On a 1-bit or 16-gray screen, does a scaled-up comic still look sharp enough? Check a sample on the real 9.7" screen.
- Should
max_width/max_height(which skip large comics) change with it?
Done when: comics fill their block well on the 9.7", 7.5" and 5.65" sample images, the default is decided with txoof, the help text of enlarge explains it, and the sample images are made again.
- Lenguaje dominante
- Python
- Estrellas
- 205
- Forks
- 17
- Merge medio
- 4 h 8 min
- PR fusionados (30 d)
- 72
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Sin guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de txoof/PaperPi
-
enhancement
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
area:plugins enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
area:core needs-decision
Dificultad 5/5 Más de una semana Aptitud para principiantes 32/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
Todos los issues de txoof/PaperPi
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
google-agentic-commerce/AP2#388 ·
-
area:codegen backend:cuda backend:hip bug direction:input
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
CrossGL/crosstl#3061 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
rlaope/oh-my-hermes#2304 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
mochan-tk/agentic-dev-kit-for-codex#64 ·
Los mantenedores suelen responder en 1 día
-
Windows ARM memory-leakAbiertobug docs performance
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
Los mantenedores suelen responder en 3 días