problem with non-printing hex 0x0C
I had a problem that kept me busy for a few hours. A \page command had no effect, the text just continued in the pdf. The culprid turned out to be a hex 0x0C, a formfeed character. Once I removed them all was good. It got introduced by extracting the text from a PDF. I realize my files should be "clean" of control characters and ConTexT should (maybe) not be stripping those characters. Then again, they serve no purpose in the document. So... My question: Isn't some more resilience sensible so commands don't break? Or error messages? cheers and thanks for any thoughts. Martin For the record: ConTeXt ver: 2019.01.28 16:58 MKIV beta fmt: 2019.2.4 int: english/english I'm not sure if the FF makes it through the mail. A hex editor will/would show it in front of the \page (sheer coincidence) \starttext \startitemize[columns] \item auf \hl[6]~ Baum \stopitemize \page 1. Der Bauer sitzt auf \hl[6]~ Traktor. \stoptext
On 2/5/2019 9:28 PM, martin wrote:
I had a problem that kept me busy for a few hours. A \page command had no effect, the text just continued in the pdf.
The culprid turned out to be a hex 0x0C, a formfeed character. Once I removed them all was good. It got introduced by extracting the text from a PDF.
I realize my files should be "clean" of control characters and ConTexT should (maybe) not be stripping those characters. Then again, they serve no purpose in the document. So...
My question: Isn't some more resilience sensible so commands don't break? Or error messages?
a formfeed is acting like a newline \catcode\tabasciicode \spacecatcode \catcode\endoflineasciicode \endoflinecatcode \catcode\formfeedasciicode \endoflinecatcode \catcode\spaceasciicode \spacecatcode ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
martin