groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Gardner
Subject: Re: [groff] Now online: gropdf / grops previewer
Date: Fri, 4 May 2018 20:15:51 +1000

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 <canvas> 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, <canvas> is annoyingly limited
<https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D#Text_styles>
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, <canvas> is pretty low-level in its drawing facilities. It even
resembles PostScript in both its naming choices (lineTo
<https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/lineTo>,
moveTo
<https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/moveTo>,
strokeStyle
<https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/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 <canvas> 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 <address@hidden> 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 <canvas> 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
>
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]