Linear barcode text options being ignored

[softhorizons]

In relinear.ps, line 196 reads:
textxalign (unset) eq textyalign (unset) eq and alttext () eq and {

This is intended to special-case trivial text rendering, but will unexpectedly cause textxoffset, textyoffset, textgaps to be ignored when the user is allowing textxalign & textyalign to just use defaults.
It would makes sense to add checks for non-zero textxoffset, textyoffset & textgaps, but I'd be tempted to just get rid of the whole special-case business entirely since I don't expect it saves enough time to be worth it.

[terryburton]

It's not intended as an optimisation. When textxalign (unset) eq textyalign (unset) eq and alttext () eq and is true, the renderer will use the text positions supplied by the encoder. Consider EAN/UPC/ISBN as an example of where this matters.

textxalign and textyalign are still honoured under these conditions and apply to the positions set by the encoder. textgaps is not honoured because it makes no sense when the placement is decided by the encoder.

Setting another alignment "mode" causes the encoder-indicated positions to be ignored and string placement to be used instead.

Do you have some examples for options strings that lead to surprising results? It might the that we can take the opportunity to tweak things to follow the principle of least surprise.

[softhorizons]

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.

[terryburton]

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.

[softhorizons]

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!