ASCII Novel Text Art

Here's the one that justifies the pack. ASCIINovelTextArt takes an image, pixelates it into a grid, and then fills every cell with the next character from a text file - left to right, top to bottom - until the whole grid is consumed. The output is a high-resolution image whose "ASCII" is actually your story, your poem, your lyrics. Take a scene image from your generation, feed it the novel's text, and you get a poster that is simultaneously a picture and a page.

The author's design doc (included in the repo) frames it as the two-node workflow for exactly this: the ASCIITextLayoutPlanner first, to size things up, then this node to actually render. It's a genuinely cool use of the color-ASCII machinery - unlike the base nodes which pick characters by luminance, this one ignores the glyph's meaning entirely and just burns through your text stream.

How it works

Your image is pixelated into a grid - grid_width = image_width // pixel_size cells across, grid_height based on pixel_size * aspect_ratio_correction - and each cell gets one character from your file. The text is treated as a continuous stream: newline_mode decides whether line breaks in the file are stripped (remove, the default), turned into spaces (space), or kept (preserve). Each character is drawn at font_size and colored per char_color_mode: sampled_color (default) grabs the cell's color, or you can go grayscale, black, or knockout_white - the last one punches white glyph shapes out of the image so it reads as white text on the picture. background_mode picks what sits behind the glyphs (white canvas by default, source_image for the underlying photo look).

The blend knobs are what make it look like a picture instead of a wall of text: text_opacity (0.55) controls how solid the glyphs are, blend_strength (0.8) how much the source image shows through, and adaptive_font_strength (0.35) scales the effect based on image content.

The inputs and outputs that matter

The file itself comes in through text_file_path - per the author's tooltip, a .txt file stored in ComfyUI's input folder. There's a proper upload area on the node: it posts to a custom /asci/upload-text route that writes your file into the input directory, so you can just drag a text file onto the node rather than manually moving it around. Only .txt is accepted.

The star of the show is the output side, because this node tells you things instead of just rendering:

• IMAGE - the finished art, at image_width * resolution_scale × image_height * resolution_scale.
• used_chars / required_chars - how many characters the grid needed versus how many your file actually had. If used_chars comes out lower, your grid wanted more text than you gave it.
• report_text - a string with diagnostics, including which characters your font can't render.

Watch text_shortage_mode (default loop): when the file runs out before the grid does, it loops back to the start, or can error or blank-pad depending on what you pick.

Installing it

It's part of the one-pack install - nothing special:

cd ComfyUI/custom_nodes
git clone https://github.com/Shiba-2-shiba/comfyui-color-ascii-art-node.git
cd comfyui-color-ascii-art-node
pip install -r requirements.txt

Restart, then find it under Image Processing / ASCII Art. No models, no keys, no API.

Where people get burned

Font support is the whole ballgame here. Your text file can contain any characters, but if the selected font can't draw them you get tofu boxes or blanks - which is why glyph_check_limit and report_text exist: the node inspects your text against the font (up to 5,000 glyphs by default) and reports the unsupported ones. Japanese novel text with the default Chewy-Regular.ttf (a Latin display font) will fail; the pack bundles NotoSansJP-VariableFont_wght.ttf precisely for this, and the author's spec recommends it for Japanese content. Run the planner first, check required_chars against your file length, and match font to language before you queue the render.