Toward a Digital Comics Praxis | Hacker News Reader

Toward a Digital Comics Praxis

digitalcomics.co

45 pointssolarized19 comments

I'm not a comic reader, but if anyone's interesting in the related media-theory, these two popular books should prove relevant:

- [scottmccloud.com - Understanding Comics](https://scottmccloud.com/2-print/1-uc/)

- [Ways of Seeing - Wikipedia](https://en.wikipedia.org/wiki/Ways_of_Seeing)

See also (or first!) this closely related, amazing work, "Unflattening", by Nick Sousanis:

https://en.m.wikipedia.org/wiki/Unflattening

https://www.hup.harvard.edu/catalog.php?isbn=9780674744431&c...

It's not really actionable for most comics makers, because there isn't a standard toolchain to point to, other than "learn web technologies, mash them into shape, pray it doesn't break". Splitting up the comic into various assets for panel layouts, lettering, etc all comes at a cost in terms of software dependencies.

The advantage of sticking to a traditional "plain image" with scrolling or pages is that the information is consistent, easy to parse, and robust to technical changes. The work of reformatting can be delegated to a sufficiently smart client app. We have OCR, we can definitely build a panel recognizer.

The idea share the same goals with svg design. easily adapt on various screen size while maintain the image quality.

inkscape and friends has decent support to svg. html and css layouting are the simple things.

you can export it as single html files to read it offline.

just open a browser. the layout and responsiveness simply maintained.

no need to install new apps and trapped into apk hells.

I am creating a fully digital comic in HTML & CSS only. Even the illustrations are CSS generated pixel art. In case someone's interested you can find it here : https://drdru.github.io/twc/twc_save_aryn/02_on_the_way_to_k... .

That’s really neat! I’ve been looking for inspiration for a design idea like this, but CSS animation + images can get clunky. How are you handling transitions between “pages”?

Thanks. Right now it's all static. To go from one page to the other you can click 次and 前 . It would be easy to move the characters within the images using a bit of javascript. That's a plan I have for the future.

If you need inspiration you can take a look at this as well made using REXPaint. https://preview.redd.it/vxfohcwxywt71.png?width=1458&format=...

It's all ASCII art so in theory one should be able to convert it to HTML. I have a project to make a story using REXPaint to HTML in a near future.

If you need more info, feel free to contat me raising an issue on github.

How long will a comic designed with modern web standards continue to be viewable in web browsers if the creator dies or abandons it?

A lot of experimental comics from two decades ago (some of which were designed based on Flash or internet explorer features) won't load properly today.

The font choice makes it really difficult to read on my screen. The letters are extremely thin.

Complaining about bad formatting choices and other problems not related to the content is technically against the HN guidelines, which is why you're probably going to get downvoted a lot. I wish it weren't, though. If I ever write something good enough to hit the HN front page I'm going to change the font to alternating papyrus and comic sans and put auto-playing music in the background to see just how dedicated people are to this ideal of not mentioning when an article is a godawful reading experience.

Worse: the front page/ToC is not compatible with Reader mode.

Luckily, all the rest of it is.

this website was made during the ipad-pro/retina gold-rush of apple fame, low'ish contrast is another symptom

since when, even mac fanboys started to pay way more attention to general accessibility, now that Johnny Ive is no longer a default idol

Pre-web a German comic artist used an Atari ST to draw and render comics.

https://old.reddit.com/r/atarist/comments/xgs4rh/comicbook_c...

Also, Shatter was an amazing milestone at the time: https://en.wikipedia.org/wiki/Shatter_(digital_comic)

So I need to give this a more thorough read. I'm pretty into comics and related media, but looking at the PoC it presents, I don't understand why it's so janky on first view, nor why it thinks it's good to require both scrolling and pagination (it's not). On the other hand, it eschews all animation which is good. So I don't know, maybe it's not so far off, from a future web-based presentation.

Side note - For anyone interested in legacy comics stored in cbz/cbr files, I recently published my desktop (native, no electron) viewing application [0]. It's free and open source.

[0]https://github.com/mftb0/cbxv-gotk3

Not all artwork lends itself to being represented by vectors, so that's a challenge. I'm also not sure every artist wants their compositions to change depending on the device. At least not all the time. And it seems like it'd be a lot of work to try to keep the focus on the right parts of the panel and represent transitions between panels and pages in a controlled way.

I understand that digitally distributed comics present these challenges and tradeoffs, and that they're probably worth it for many people. I've never had a better comics reading experience than just a printed trade paperback collection. Harumph.

Noting that its already mentioned in article:

Instead of adjusting the aspect ratio, why not just have the frames re-order while preserving the aspect ratios, no extra "hidden" art?

Then, why break the page apart? why not just zoom to each frame? if you don't zoom all the way, then you get to include context of the frame's position in the page and story. Lower workload, fits the desired flow a lot better.

Then, well, that's already done at several comic distribution services.

- - -

The alternative is, ordered block-axis content is always responsive: Webtoons.

should ~~designers~~ comic artists (learn to) code?

not before instagram starts accepting SVG uploads

If you aren't big enough to have a working staff, you should learn everything you can that doesn't take up time you could spend doing the thing that makes you money.

If you're big enough to have staff, someone else should be doing the code so the artist can focus on the thing that makes you money.

So basically "only if you have to" and people generally don't have to.

Reply on news.ycombinator.com