OK, I see why it's not an optimization, but the comments about "unexpected" stand. I agree, "least surprise" is important, 'specially since expecting users to RTFM doesn't seem to cut it anymore.

Taking a basic code39 as an example, the all-default options case renders text below the bars, nicely x-spaced to match the bars as you describe.

Now, let's set textyalign=below, which happens to match the default. Oops! Nice x-spacing goes away! User is wondering "hmmm... I didn't really do anything, and what might y-alignment have to do with x-spacing?!" 2nd question applies to any other textyalign.

Instead, without setting textyalign, let's set textxoffset=-1 because we like the auto-spacing but want to shift text over slightly because, for example, the font we're using has slightly different x-positioning than what BWIP's auto-layout assumes. Users have their reasons. It won't work. Unless I set one of the 'align options (again, what does textyalign have to do with x offsets?), plus the auto-spacing gets blown away.

Re. textgaps not honored: BWIPP users tend to be pretty sophisticated. I'd greatly hesitate to ignore explicit commands from such users, no matter my personal notions of their intentions or sanity.

The fact that you need to enable certain options with one of the 'align options is unobvious. When you're making tools, you have no idea some of the crazy things that users (me, for example) will get up to with them, or why. I believe it was Ritchie or Stroustrup who once wrote that the usefulness of a tool is proportional to the number of uses found for it that the creator never even imagined.

That's useful. I'll give it some thought whilst I'm offline for a week or so.

The current behaviour is the result of evolution whilst maintaining back compat, rather than second guessing the intent of the user.

It seems to me that the main issue is that behaviour of the alignment strategies should be managed independently in the x and y directions so that a change in the y position should not reset the default x layout.

Agreed, and fully understand that you have installed base to deal with. Since you're "spring cleaning," I'd add:

• One would expect not specifying an option vs. specifying the default value (e.g. textyalign=bottom) to produce consistent results
• I'm unsure about the answer, but you might want to consider whether textxoffset should blow away default x layout entirely, or just shift it over
• Current behavior of not somehow honoring xoffset & gaps unless textxalign is specified is unexpected, whether that means blowing away default layout or whatever else
• It would be helpful for the documentation of the options themselves to be more explicit about interlocking text options, default text formatting. Yes, people don't RTFM... until they're desperate!