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

[Ralph Corderoy]

Hi John,

> > https://stackoverflow.com/questions/11332608/ may also be useful if
> > you're not used to affine transformations for 2D graphics.
>
> Ah, that doesn't really apply here because a separate  element
> is used for each individual page: the viewer's layout is handled using
> plain HTML/CSS (for both performance and simplicity reasons).

Yes, I thought each page was a separate .  I don't see why that
Q doesn't apply though since it's only talking about zooming on a
single canvas and wanting to translate, i.e. slide, the zoomed image so
a desired area is visible.  But as long as you're happy, that's fine.
`Release early, release often'.  :-)

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

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

[John Gardner]

Hey Ralph,

Sorry about the slow reply: I missed your email completely! Didn't even
notice that you'd responded...

> 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?

Yes, rasterisation is handled by the browser's usual facilities for
text-rendering. In fact,  is annoyingly limited

in this department – authors have little control over how fonts are
*selected*, let alone rendered. Nonetheless, I'm grateful I don't have to
implement rasterisation myself. :)

Normally,  is pretty low-level in its drawing facilities. It even
resembles PostScript in both its naming choices (lineTo
,
moveTo
,
strokeStyle
,
etc) and its concept of a "stack" of drawing states (which encapsulate
transforms, stroke and fill styles, etc). Its limited font-handling support
is therefore quite ironic.

> Someone else already mentioned the probable area to look in, but
> https://stackoverflow.com/questions/11332608/ may also be useful
> if you're not used to affine transformations for 2D graphics.

Ah, that doesn't really apply here because a separate  element is
used for each individual page: the viewer's layout is handled using plain
HTML/CSS (for both performance and simplicity reasons).

Think I'll just cut a release without animated zooms, because animation is
what's making this a UX issue. Sane authors would have realised this ages
ago, but I'm not that sane (or I'm just too much of a perfectionist...)

On 27 April 2018 at 00:20, Ralph Corderoy  wrote:

> 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] 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] Now online: gropdf / grops previewer

[John Gardner]

Thanks for the kind words! =)

> this previewer is only a part of the online troff
> editor you are working on isn't it?

Ah no, it's not an online, interactive version of Troff, if that's what
you're thinking. =)

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.

> I have used heirloom troff for years, and felt very lonely. Karsten
> Kunze seemed to be the only other person on earth interested with
> that software. I'm not certain it is worth your time working on
> compatibility with heirloom troff.

Well, I'm certainly interested. Heirloom is very unacknowledged and has a
lot to offer authors by way of font support and microtypography.

Moreover, this is less about supporting individual Troff implementations
and more to do with having a consistent representation of output.


On 25 April 2018 at 01:26, Pierre-Jean Fichet 
wrote:

> John Gardner  wrote:
> > Well, here it is:
> > https://rawgit.com/Alhadis/Roff.js/web-demo/index.html
>
> It is nice to see our old troff on the web, thank you for
> the hard work!
>
> If I remember correctly your other posts, this previewer is
> only a part of the online troff editor you are working on,
> isn't it?
>
> I also noticed you were thinking about a troff to xml converter. May I
> suggest you to have a look at my own "proof of concept" on that
> matter:  (I posted some mails about it on
> that list a few months ago). It is not especially a great piece of
> software, but I believe the idea of using nroff, with a macro made for
> the purpose of the conversion, still worth being considered. At
> least, I'd be glad to hear criticisms if it is not.
>
> >- *Heirloom Troff output isn't perfect.* This is a known issue I
> intend
> >to fix in a future release. At the moment, the renderer is heavily
> reliant
> >on the ‘w’ and ‘n’ output commands to identify where a word ends.
> Groff
> >uses these sequences consistently, but Heirloom doesn't.
>
> I have used heirloom troff for years, and felt very lonely. Karsten
> Kunze seemed to be the only other person on earth interested with
> that software. I'm not certain it is worth your time working on
> compatibility with heirloom troff.
>
> Kind Regards,
> Pierre-Jean.
>
>

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

[Pierre-Jean Fichet]

John Gardner  wrote:
> Well, here it is:
> https://rawgit.com/Alhadis/Roff.js/web-demo/index.html

It is nice to see our old troff on the web, thank you for
the hard work!

If I remember correctly your other posts, this previewer is
only a part of the online troff editor you are working on,
isn't it?

I also noticed you were thinking about a troff to xml converter. May I
suggest you to have a look at my own "proof of concept" on that
matter:  (I posted some mails about it on
that list a few months ago). It is not especially a great piece of
software, but I believe the idea of using nroff, with a macro made for
the purpose of the conversion, still worth being considered. At
least, I'd be glad to hear criticisms if it is not.

>- *Heirloom Troff output isn't perfect.* This is a known issue I intend
>to fix in a future release. At the moment, the renderer is heavily reliant
>on the ‘w’ and ‘n’ output commands to identify where a word ends. 
> Groff
>uses these sequences consistently, but Heirloom doesn't.

I have used heirloom troff for years, and felt very lonely. Karsten
Kunze seemed to be the only other person on earth interested with
that software. I'm not certain it is worth your time working on
compatibility with heirloom troff.

Kind Regards,
Pierre-Jean.

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

[John Gardner]

Hey Larry,

> If it can update live, I’d use it as a previewer

Well, it can. But I'm not expecting anybody to write and edit ditroff
source by hand.

The web-based viewer is really a dumbed-down version of an Atom
 extension I've nearly finished. The Atom editor will be
able to perform live updates because it can pipe to/from programs in the
user's environment.

I anticipate the result will be quite flashy, but the web-based viewer does
little to convey that...



On 24 April 2018 at 13:11, Larry Kollar  wrote:

>
> John Gardner  wrote:
>
> > Well, here it is:
> >
> > https://rawgit.com/Alhadis/Roff.js/web-demo/index.html <
> https://rawgit.com/Alhadis/Roff.js/web-demo/index.html>
>
> Oh, cool. It’s like a web version of xditview(1). If it can update live,
> I’d use it as a previewer.
>
> Larry
>
>

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

[Larry Kollar]

John Gardner  wrote:

> Well, here it is:
> 
> https://rawgit.com/Alhadis/Roff.js/web-demo/index.html 
> 

Oh, cool. It’s like a web version of xditview(1). If it can update live,
I’d use it as a previewer.

Larry

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

[John Gardner]

Hey Branden,

> I'd love to see what the source looks like, but when I alter the URL, I
> get a bunch of 404s.

Everything is on GitHub . The
browser-friendly version is on a separate branch
, as I had to do a few
hacks to address the dependencies on an Electron/Node.js environment.

However, the code for panning and zooming was made a separate project
. Achieving the effect in a
browser-efficient manner was oddly involved, and it felt too heavyweight to
lump in with the rest of the Roff-specific work. The code works, I just
realised I need to clamp it to a certain range.

Trouble is, that range will vary. Zooming won't always be smack in the
dead-centre, either. While not implemented in the web-demo, there will be a
"double-click to zoom in" functionality that should logically centre on
wherever the user clicked.

Complicating matters further is the fact the window pane's width will vary
depending on how wide the user's scaled it, and the fact that manually
setting scroll offsets to compensate for zooming causes a visible "jolt"
because they happen on different redraws... I may have to implement
scrolling manually.

I found a possible Unicode handling problem. In the attached ditroff
> output, note that the angle brackets around the email address in the
> "AUTHORS" section are rendered as different glyphs altogether.


I'm seeing angle brackets: ⟨ ⟩, U+27E8 and U+27E9, respectively. This may
be font-related. The "special" font is used for displaying symbols, which
maps to the first available font in the following list:

- Standard Symbols PS
- Standard Symbols L
- Symbol
- serif
- oblique


The first two are included in the URW Base35 fonts, which as I explained
are sanely omitted from the web-demo, as it would add a big hit to
load-time. =) Could you try installing the StandardSymbolsPS font from
GhostScript's fonts repo?


On 23 April 2018 at 09:34, G. Branden Robinson  wrote:

> At 2018-04-23T09:04:25+1000, John Gardner wrote:
> > Well, here it is:
> >
> > https://rawgit.com/Alhadis/Roff.js/web-demo/index.html
> >
> > Some modifications were needed for web-delivery, and performance still
> > isn't optimal, but it works. You'll need a relatively recent browser to
> use
> > it (anything released within the last year should do).
> >
> > Few things to note before you try it:
>
> This looks fantastic!  Thank you for doing this work!
>
> I'd love to see what the source looks like, but when I alter the URL, I
> get a bunch of 404s.
>
> >- *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.
>
> I found a possible Unicode handling problem.  In the attached ditroff
> output, note that the angle brackets around the email address in the
> "AUTHORS" section are rendered as different glyphs altogether.
>
> >- *There's an issue with zooming.* This is what I'm stuck on, and when
> >Branden offered help with matrix calculations, I decided the best way
> of
> >explaining was with a working demo.
> >
> >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.
>
> I see what you mean.  I don't think there's a matrix math problem here.
> If I had to guess, you are doing a coordinate transform from document
> coordinates to canvas (and/or browser window) coordinates, and clamping
> the wrong pair.
>
> For instance, if I zoom a document to 150%, there is obviously document
> content off-screen to the left.  So the x coordinate is negative in the
> browser window, but of course it is still positive in the document's
> coordinate frame.
>
> I know nothing about JavaScript frameworks (apart from the existence of
> this "canvas" thing, which is a fairly generic term for a drawing window
> anyway).
>
> Anyway, if I can get my hands on the source, maybe we can put our heads
> together on the problem.
>
> Great work!
>
> --
> Regards,
> Branden
>

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

[G. Branden Robinson]

At 2018-04-23T09:04:25+1000, John Gardner wrote:
> Well, here it is:
> 
> https://rawgit.com/Alhadis/Roff.js/web-demo/index.html
> 
> Some modifications were needed for web-delivery, and performance still
> isn't optimal, but it works. You'll need a relatively recent browser to use
> it (anything released within the last year should do).
> 
> Few things to note before you try it:

This looks fantastic!  Thank you for doing this work!

I'd love to see what the source looks like, but when I alter the URL, I
get a bunch of 404s.

>- *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.

I found a possible Unicode handling problem.  In the attached ditroff
output, note that the angle brackets around the email address in the
"AUTHORS" section are rendered as different glyphs altogether.

>- *There's an issue with zooming.* This is what I'm stuck on, and when
>Branden offered help with matrix calculations, I decided the best way of
>explaining was with a working demo.
> 
>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.

I see what you mean.  I don't think there's a matrix math problem here.
If I had to guess, you are doing a coordinate transform from document
coordinates to canvas (and/or browser window) coordinates, and clamping
the wrong pair.

For instance, if I zoom a document to 150%, there is obviously document
content off-screen to the left.  So the x coordinate is negative in the
browser window, but of course it is still positive in the document's
coordinate frame.

I know nothing about JavaScript frameworks (apart from the existence of
this "canvas" thing, which is a fairly generic term for a drawing window
anyway).

Anyway, if I can get my hands on the source, maybe we can put our heads
together on the problem.

Great work!

-- 
Regards,
Branden
x T pdf
x res 72000 1 1
x init
p1
x font 5 TR
f5
s1
V48000
H72000
md
DFd
tPIC2GRAPH(1)
h111510
tGeneral
wh2500
tCommands
wh2500
tManual
h111510
tPIC2GRAPH(1)
n12000 0
V84000
H72000
x X devtag:.NH 1
x font 16 TB
f16
s10950
V84000
H72000
tN
H79687
tAME
wh2738
x X devtag:.eo.h
V84000
H107972
n12000 0
f5
s1
V96000
H108000
tpic2graph
wh2500
C\-
wh8140
tcon
H172670
tv
H177520
tert
wh2500
ta
wh2500
tPIC
wh2500
tdiagram
wh2500
tinto
wh2500
ta
wh2500
tcropped
wh2500
timage
n12000 0
V112800
H72000
x X devtag:.NH 1
f16
s10950
V112800
H72000
tSYNOPSIS
wh2738
x X devtag:.eo.h
V112800
H128283
n12000 0
V124800
H108000
x X devtag:.col 1
s1
V124800
H108000
tpic2graph
wh2500
x X devtag:.col 2
f5
V124800
H153840
t[
f16
C\-
h5700
tunsafe
f5
t]
wh2500
t[
f16
C\-
h5700
tf
H208590
tormat
x font 18 TI
f18
h2500
toutput-format
f5
h680
t]
wh2500
t[
f16
C\-
h5700
teqn
f18
h2500
tdelimeter
f5
h730
t]
wh2500
t[
f18
h200
tcon
H388250
tvert-options
f5
h270
t]
n12000 0
V141600
H72000
x X devtag:.NH 1
f16
s10950
V141600
H72000
tDESCRIPTION
wh2738
x X devtag:.eo.h
V141600
H150787
n12000 0
f5
s1
V153600
H108000
tReads
wh2500
ta
wh2500
tPIC
wh2500
tprogram
wh2500
tas
wh2500
tinput;
wh2500
tproduces
wh2500
tan
wh2500
timage
wh2500
Cfi
h5560
tle
wh2500
t(by
wh2500
tdef
H354250
tault
wh2500
tin
wh2500
tPortable
wh2500
tNetw
H439420
tork
wh2500
tGraphics
wh2500
tformat)
n12000 0
V165600
H108000
tsuitable
wh2500
tfor
wh2500
tthe
wh2500
tW
H179130
teb
wh2500
tas
wh2500
toutput.
wh5000
tAlso
wh2500
ttranslates
wf16
h2500
teqn
f5
t(1)
wh2500
tconstructs,
wh2500
tso
wh2500
tit
wh2500
tcan
wh2500
tbe
wh2500
tused
wh2500
tfor
wh2500
tgenerating
wh2500
timages
wh2500
tof
n12000 0
V177600
H108000
tmathematical
wh2500
tformulae.
n12000 0
V194400
H108000
tPIC
wh2500
tis
wh2500
ta
wh2500
trather
wh2500
te
H172280
txpressi
H200360
tv
H205210
te
wh2500
tgraphics
wh2500
tminilanguage
wh2500
tsuitable
wh2500
tfor
wh2500
tproducing
wh2500
tbox-and-arro
H448240
tw
wh2500
tdiagrams
wh2500
tof
wh2500
tthe
n12000 0
V206400
H108000
tkind
wh2500
tfrequently
wh2500
tused
wh2500
tin
wh2500
ttechnical
wh2500
tpapers
wh2500
tand
wh2500
tte
H294200
txtbooks.
wh5000
tThe
wh2500
tlanguage
wh2500
tis
wh2500
tsuf
H411160
Cfi
h5560
tciently
wh2500
Cfl
h5560
te
H456290
txible
wh2500
tto
wh2500
tbe
wh2500
tquite
n12000 0
V218400
H108000
tuseful
wh2500
tfor
wh2500
tstate
wh2500
tcharts,
wh2500
tPetri-net
wh2500
tdiagrams,
wh2500
Cfl
h5560
to
H287720
tw
wh2500
tcharts,
wh2500
tsimple
wh2500
tcircuit
wh2500
tschematics,
wh2500
tjumper
wh2500
tlayouts,
wh2500
tand
wh2500
tother
n12000 0
V230400
H108000
tkinds
wh2500
tof
wh2500
tillustration
wh2500
tin
H196220
tv
H201020
tolving
wh2500
trepetiti
H257160
tv
H262010
te
wh2500
tuses
wh2500
tof
wh2500
tsimple
wh2500
tgeometric
wh2500
tforms
wh2500
tand
wh2500
tsplines.
wh5000
tBecause
wh2500

[groff] Now online: gropdf / grops previewer

[John Gardner]

Well, here it is:

https://rawgit.com/Alhadis/Roff.js/web-demo/index.html

Some modifications were needed for web-delivery, and performance still
isn't optimal, but it works. You'll need a relatively recent browser to use
it (anything released within the last year should do).

Few things to note before you try it:

   - *This is a post-processor.* Make sure you use groff's -Z switch (or
   troff directly) if you're testing it with your own documents. You'll
   need to pipe it to your system's clipboard and paste it into the *Edit
   Source* dialogue.

   Normally, Atom handles this procedure transparently by piping the
   editor's contents through Groff in a separate process. Webpages don't have
   access to system binaries (thankfully), so this is the best I can do.

   - *Heirloom Troff output isn't perfect.* This is a known issue I intend
   to fix in a future release. At the moment, the renderer is heavily reliant
   on the ‘w’ and ‘n’ output commands to identify where a word ends. Groff
   uses these sequences consistently, but Heirloom doesn't. They're also
   omitted from certain eqn(1) constructs which also need fixing.

   - *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.

   I have this taken care of by bundling
    with the editor-package
   all 35 URW's core fonts. For the sake of your bandwidth, I've opted *not* to
   embed ~3 MBs of fonts into the page: if basic fonts seem to be missing, you
   can probably fix it by installing the fonts from upstream
   

   .

   - *There's an issue with zooming.* This is what I'm stuck on, and when
   Branden offered help with matrix calculations, I decided the best way of
   explaining was with a working demo.

   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.

Other than that, enjoy!

- John