SDXL Prompt Handling (JPS)

SDXL's most confusing quirk for anyone coming from SD 1.5 is that it wants two text inputs instead of one - text_g and text_l - because it runs on dual text encoders (OpenCLIP-ViT/bigG paired with CLIP-ViT/L), and the second encoder is genuinely where a chunk of SDXL's extra prompt control over composition and lighting comes from. The problem is nobody tells you clearly what to actually put in each box, so most people either duplicate the same prompt into both and hope, or improvise something ad hoc. This node turns that improvisation into a menu of named, repeatable strategies.

You give it pos_g and pos_l as two separate text strings, plus a handling mode that decides what to actually do with them. The eight options cover the full range of reasonable approaches: copy one into both if the other is empty, use them genuinely separately as written, force-copy G into both slots (or L into both), ignore one entirely, or combine them together - either G-then-L or L-then-G order. Whatever the mode produces comes back out as pos_g and pos_l, ready to wire straight into a CLIPTextEncodeSDXL node's matching inputs.

Why this matters more than it sounds. The two encoders aren't redundant - they see and weight your prompt differently, and how you split (or don't split) your prompt text between them measurably changes the output. Instead of learning that nuance from scratch, this node gives you named presets for the strategies people actually settle on: some workflows want the exact same description in both because they don't want to think about it, some want the G channel doing scene/composition work while L handles finer detail phrasing, and some just want one combined string duplicated with a sensible ordering. Having eight explicit, labeled modes means you can experiment with which one your particular checkpoint responds best to without hand-editing two text boxes every time.

Where it fits. This sits between your prompt-writing step (plain text, or JPS's own SDXL Prompt Styler if you're using style templates) and CLIPTextEncodeSDXL. It's a pure text-transform node - no image, no latent, just two strings in, one handling decision, two strings out.

Installing it. ComfyUI Manager (search "JPS Custom Nodes for ComfyUI"), or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/JPS-GER/ComfyUI_JPS-Nodes.git

Restart and it's under JPS Nodes/Text. Remove any previous copy of the pack first if reinstalling, per the author's own instructions. No models, no extra dependencies - pure string logic.

Troubleshooting. The most common confusion isn't a bug in the node, it's picking a mode that doesn't match your intent - for instance, choosing "Ignore Positive_L Input" and then wondering why text you typed into pos_l never shows up anywhere downstream; that's the mode working exactly as named. If your output looks wrong, the fix is almost always re-reading the eight mode names carefully rather than debugging the node itself - they're plainly labeled, but it's easy to grab the wrong one out of habit. And remember this node only handles the text side of the SDXL dual-encoder split; it has no opinion on text_g/text_l for the negative prompt, so if you want the same kind of handling there, you're doing it manually or with a second instance of this node.