Re: [groff] Now online: gropdf / grops previewer

[Pierre-Jean Fichet]

John Gardner  wrote:
> It's an extension for a text editor named Atom , which is
> like Emacs or Vim except graphical. Atom runs on a framework called Electron
> , which uses web technologies (HTML/CSS/JS) for
> creating desktop applications. This foundation is what's enabled me to
> share my work as an online previewer. But the full experience can't be
> ported to the browser, since it needs to shell out to Troff to process its
> output.

Ah... I thought atom was an online editor of some kind... Thank you
for the details!

Pierre-Jean.

Re: [groff] Now online: gropdf / grops previewer

[Ralph Corderoy]

Hi John,

> https://rawgit.com/Alhadis/Roff.js/web-demo/index.html
...
>- *Some fonts may look different.* Browsers handle font-rendering,
>which means the base 35 PDF fonts won't be visible in the renderer
>unless they've also been installed in your system's usual fonts
>directory.

Am I right in understanding your Javascript asks the  widget to
render some text in a particular font, size, and location, and what
pixels are set, e.g. for anti-aliasing, are up to the browser's
implementation?

>If you zoom in using the *100%* menu, you'll notice you can't
>scroll left or upwards. That's because the page contents extend
>past the top-left corner of the browser window, and we all know you
>can't scroll past the window's origin corner.

Someone else already mentioned the probable area to look in, but
https://stackoverflow.com/questions/11332608/understanding-html-5-canvas-scale-and-translate-order
may also be useful if you're not used to affine transformations for 2D
graphics.  If you can multiply a 3×1 matrix by a 3×3 matrix then you
should be able to figure it out.
https://www.willamette.edu/~gorr/classes/GeneralGraphics/Transforms/transforms2d.htm
looks like a reasonable intro from a quick skim.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

Re: [groff] groff as the basis for comprehensive documentation?

[Ralph Corderoy]

Hi Steve,

> I'm not sure why you consider `.\&' important: is that for
> end-of-sentence recognition?

No, the opposite, it's to stop an end-of-sentence character being taken
as the end of a sentence.

> I've never used double spaces for sentences, but I recognize there are
> good arguments in favour of it.

If your input has only a single space after the full stop that is the
end of a sentence but not the end of a line, then it will typeset
different to one that does fall at the end of a line.  Compare
`appropriate.' and `wrong.'.

$ nroff <<\E | grep .
.na
Indeed, I did have a relationship with Miss Lewinsky that was not
appropriate. In fact, it was wrong.
It constituted a critical lapse in judgment and a personal failure
on my part for which I am solely and completely responsible.
E
Indeed, I did have a relationship with Miss Lewinsky that was not
appropriate. In fact, it was wrong.  It constituted a critical
lapse in judgment and a personal failure on my part for which I
am solely and completely responsible.
$ 

I prefer the troff norm of a wider space, but have to look out for `Data
by Spock et al.\& shows' because editing the input might place the `.\&'
at the end of a line.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy