# [NTG-context] "fake" space for better reflow

Hans Hagen pragma at wxs.nl
Wed Nov 30 22:18:21 CET 2016

```On 11/30/2016 5:58 PM, Ulrike Fischer wrote:
> Am Wed, 30 Nov 2016 12:45:17 +0100 schrieb Hans Hagen:
>
>> On 11/30/2016 10:09 AM, Ulrike Fischer wrote:
>>> If I compile a small document
>>>
>>> \starttext
>>> \input knuth
>>>
>>> \stoptext
>>>
>>>
>>> and then use in the adobe reader "view->zoom->reflow" I get as
>>> result
>>>
>>> Thus,Icametotheconclusionthatthedesignerofanewsystemmustnotonlybetheimplementerandfirstlarge--scaleuser;thedesignershoulda
>
>> Cut and paste goes well so I think it's a bug in acrobat then.
>
> I'm not sure. Imho cut and paste use an heurisitic more or less
> based on the size of the space (there are quite a number of
> questions on tex.SX where the heuristic fails, e.g. in code
> listings), while reflow seems to need glyphs. The speech of Ross
> Moore on TUG14 seems to indicate that \pdfinterwordspaceon was
> introduced in pdftex to get around this problem.
>
> http://river-valley.zeeba.tv/%E2%80%9Cfake-spaces%E2%80%9D-with-pdftex%E2%80%94best-of-both-worlds/

I assume that it just runs over the resulting list and replaces skips by
spaces. One cannot in an earlier stage use spaces instead of skips
simply because tex has a glue based model.

So, one can kick in some callback (before shipout) and  replace glue by
space characters.

>>> I know it is due to the missing space glyph. With pdflatex I would
>>> try to use \pdfinterwordspaceon but this primitive never found its
>>> way into luatex. Is there any solution? (One that could be
>>> translated to lualatex would be best).
>
>> One can write a filter that does it before shipout. Typically a case for
>> callbacks.
>
> Well the main question is, what is the "does it" in this case.
> pdftex inserts a space from a dummy.pdf. One use the fake space more
> or less like this:
>
> \pdfinterwordspaceon
> \pdfmapline{=dummy-space <dummy-space.pfb}
> \pdfglyphtounicode{space}{0020}
> XXX YYY
> \bye

Well, just insert char 32 which is in most fonts ... (could even be a
virtual char). We will not introduce such mechanisms in luatex, after
all a macro package can decide for other criteria.

> But this doesn't sound like the correct way to go in a unicode/open
> type world.
>
> (I'm also not quite if shipout is the correct time. Imho one would
> probably avoid to add spaces e.g. in math).

One can recognize math. If context can do it (when a user enables it)
... any macro package can ...

Hans

-----------------------------------------------------------------