At 2011-08-17 04:19 -0700, Martin Abbott wrote:
>I have a Barcode font installed and when I use this in Word, say, to create
>some text a space is correctly show as the Barcode equivalent of that space.
>When I use this font in my stylesheet, whilst text is correctly displayed as
>a barcode, the space within it is shown as a space, not a barcode equivalent
>of a space.
That could be your engine's choice to treat white space as
"untouched" and simply reposition the following non-white-space
character at its correct coordinate.
Not that that is correct! I'm just sayin' that is what might be
happening. It came to mind that the tool might be making this
assumption. The XSL-FO specification determines that a space belongs
at a particular point on the page, but I don't think the
specification mandates how that space is effected on the result. The
method of rendering the information the formatter has formatted is
outside of the XSL-FO specification.
>I've played around with white-space-treatment and even used the Unicode for
>a space but no luck.
> <fo:block space-before="2cm">
> <fo:inline font-size="36pt" font-family="3 of 9 Barcode">Some
>Does anyone have any ideas?
Not if the culprit is your XSL-FO engine's interpretation of a space
character as being the absence of a graphic.
Does your font have a copy of the space character at a different
location in the character map? Then you could in your XSLT translate
the space character of your data to the alternative space character
with the required glyph.
If you have the tools to edit your font file, you could do this
yourself by sacrificing one of the characters you plan not to use.
A quick Google search of character sets for 3 of 9 found me this font file:
After reading about this a bit more it would appear as though a space is a valid character in Code 39 barcodes so should be rendered. Indeed using the installed font in Wordpad generates a readable barcode with a space encoded and then read back successfully without any problems.
I've found a font that does what you suggested and has the space character moved to "~" and I've tried a different engine but still no joy unfortunately.
At 2011-08-18 06:58 -0700, Martin Abbott wrote:
>After reading about this a bit more it would appear as though a space is a
>valid character in Code 39 barcodes so should be rendered. Indeed using the
>installed font in Wordpad generates a readable barcode with a space encoded
>and then read back successfully without any problems.
Totally understood. I wasn't refuting there was a problem.
>I've found a font that does what you suggested and has the space character
>moved to "~"
At 2011-08-18 08:25 -0700, Martin Abbott wrote:
>Thanks Ken, I'll give that a go.
>I'll have to chuck it through the XSLT engine in .NET first if I'm to use
>the translate I guess as the renderer I'm using only renders the raw XSL-FO
>so bails on the <xsl:value-of/>.
Well, your code fragment you gave in your original post was an XSLT
stylesheet and so I framed my suggestion using your code. You should
be able to create the XSL-FO file with the translated characters.