Images with text are multipart: jskom and the Emacs client can't show them #329

New issue

Closed

opened 2026-10-24 21:28:55 +00:00 by littlefox · 1 comment

littlefox commented

2026-10-24 21:28:55 +00:00

Owner

Reported by the user: their profile picture, uploaded with NeoKOM, shows in jskom as [unknown content-type: "multipart/mixed;boundary="neokom-9e3769f4""], and the Emacs client can't show it either.

Cause: an image with text (a caption, or a presentation's text) is written as multipart/mixed. jskom renders only text/* and image/* (partials/text.html); the Emacs client says "< Flerdelade inlägg (…) stöds inte. >" (lyskom-format-multipart). Both show image/* texts (subject line, then the raw image). jskom itself posts an image as the whole text, never with a caption. DESIGN's "as jskom does" was wrong for the captioned case.

Decided (D-067): the text is posted as usual, and the image follows as an image/* footnote by the same author. The Emacs client reads it right after the text; jskom lists it as a footnote; NeoKOM draws footnotes inside the post. An image without text stays one image text. Presentations the same; the avatar is also found in the presentation's footnotes. Old multipart posts stay; NeoKOM keeps reading multipart. The user re-saves their presentation once the fix is out.

Reported by the user: their profile picture, uploaded with NeoKOM, shows in jskom as `[unknown content-type: "multipart/mixed;boundary="neokom-9e3769f4""]`, and the Emacs client can't show it either. Cause: an image with text (a caption, or a presentation's text) is written as `multipart/mixed`. jskom renders only `text/*` and `image/*` (`partials/text.html`); the Emacs client says "< Flerdelade inlägg (…) stöds inte. >" (`lyskom-format-multipart`). Both show `image/*` texts (subject line, then the raw image). jskom itself posts an image as the whole text, never with a caption. DESIGN's "as jskom does" was wrong for the captioned case. Decided (D-067): the text is posted as usual, and the image follows as an `image/*` footnote by the same author. The Emacs client reads it right after the text; jskom lists it as a footnote; NeoKOM draws footnotes inside the post. An image without text stays one image text. Presentations the same; the avatar is also found in the presentation's footnotes. Old multipart posts stay; NeoKOM keeps reading multipart. The user re-saves their presentation once the fix is out.

littlefox added the

kind/bug

label

2026-10-24 21:28:55 +00:00

littlefox referenced this issue from a pull request that will close it,

2026-10-24 21:57:45 +00:00

An image with text: the text, then the image as a footnote (D-067) #330

littlefox referenced this issue from a commit

2026-10-24 21:57:46 +00:00

An image with text: the text, then the image as a footnote (D-067)

littlefox closed this issue

2026-10-24 21:57:52 +00:00

littlefox referenced this issue

2026-10-24 22:21:27 +00:00

Images with text: Protocol A says multipart, the clients show only image texts (revisit D-067?) #331

littlefox commented

2026-10-24 22:38:59 +00:00

Author

Owner

Fixed in #330; main green (run #606). D-067.

Unit tests: split_image (no multipart written).
Devserver test: the text, then the image footnote at the full budget, read back as image/jpeg; a presentation with text and a picture, avatar found in its footnote.
post-image spec: a captioned image is the text plus a footnote with the picture, drawn inside the post. profile spec: avatar from the footnote, and the editor loads it.
Full suite: 410 passed, 1 unrelated flake.

Note: Protocol A recommends multipart for this case. Whether to keep D-067 is open in #331.

Fixed in #330; main green (run #606). D-067. - Unit tests: `split_image` (no multipart written). - Devserver test: the text, then the image footnote at the full budget, read back as `image/jpeg`; a presentation with text and a picture, avatar found in its footnote. - post-image spec: a captioned image is the text plus a footnote with the picture, drawn inside the post. profile spec: avatar from the footnote, and the editor loads it. - Full suite: 410 passed, 1 unrelated flake. Note: Protocol A recommends multipart for this case. Whether to keep D-067 is open in #331.