* problem with non-printing hex 0x0C
@ 2019-02-05 20:28 martin
2019-02-06 8:51 ` Hans Hagen
0 siblings, 1 reply; 2+ messages in thread
From: martin @ 2019-02-05 20:28 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
\f\page
1. Der Bauer sitzt auf \hl[6]~ Traktor.
\stoptext
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: problem with non-printing hex 0x0C
2019-02-05 20:28 problem with non-printing hex 0x0C martin
@ 2019-02-06 8:51 ` Hans Hagen
0 siblings, 0 replies; 2+ messages in thread
From: Hans Hagen @ 2019-02-06 8:51 UTC (permalink / raw)
To: mailing list for ConTeXt users, martin
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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2019-02-06 8:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-05 20:28 problem with non-printing hex 0x0C martin
2019-02-06 8:51 ` Hans Hagen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).