Re: Lines to edges of \center-column

[David Wright]

On Sun 23 Apr 2017 at 04:12:32 (+0200), address@hidden wrote:
> On 04/23/17 03:47, David Wright wrote:
> >Then I don't know what you mean. When you drag over them, they turn
> >blue because you _have_ selected them (drag.png, apologies for the
> >size). Then you can paste them into, say, a bash shell command line
> >(pasted.png, the box at the right is the inactive cursor).
> 
> The top (kana) line can't be selected at all, is what I'm trying to
> say. It acts a bit different in different viewers, but none seem to
> be able to select+copy it.

Well, I can't take a view on that because AFAICT the source in the OP
only contained kanji (complicated-looking) characters. Would that be
correct? Could you give the source with which you produced your
seam.png output (preferably as an attachment so I don't have to rely
on my paste's behaviour).

> >But why do you want to select part of a PDF like that when _you_
> >generated it? I often do that with _other_ people's PDFs when I
> >want to get at their text.
> 
> It's not that I want to select it, it's just that I hate when things
> are inconsistent like that.
> 
> >The rendition of the dragged area is entirely a function of the
> >viewer you're using. Xpdf always shows a rectangle and lifts
> >just the text therein, rather than being constrained by the lines
> >of text (xpdf.png, more apologies). However, I think it mixes up
> >its encodings so the pasted text makes little sense.
> >
> >That looks a lot like evince that you're using. Very good for reading
> >Chase credit card statements and encrypted PDFs, which xpdf can't
> >manage, but I hate the interface.
> 
> It's actually Atril, MATE's Evince fork. I use it because it
> respects my GTK theme, and unlike Evince, it doesn't use client-side
> window decorations, so it works with i3. I think xpdf's UI looks
> horrible, btw. Its rendering quality seems good, though.

I agree, but I'm more concerned about the contents of the window than
the window itself.

> >Anyway, my guess is that evince
> >treats keeping the characters _as_ individual characters as its
> >priority, whereas xpdf tries to render what will print.
> 
> Yeah, I've noticed that Atril often renders things slightly
> differently when zoomed-out.
> 
> >One really needs an armoury of PDF viewers.
> 
> And yet, PDF's main point is that it looks identical on all devices...

Well, I've taken a closer look with evince at my box.pdf and I can see
the effect you mention. However, I think they're just artifacts of its
display, because when you magnify the areas in question, the blemishes
don't get magnified but disappear, or appear elsewhere. So I don't
think the problem lies in the PDF at all. One also has to bear in mind
that the screen resolution can lead to odd effects just because of
where the grid of pixels happen to be relative to the image.

When I wrote armoury, I really meant in terms of their functionality
rather than differences in the document display. Xpdf has flexible
navigation (by page, by 10 pages, by history, and by pagenumber),
zoom (width, height, entire page, selected area), rotation, page/
continuous view, 'q' to quit, and so on. Evince can handle some PDFs
that xpdf can't, as mentioned before, but also view different types
of document. Xournal can annotate PDFs with text and drawings. Etc.
But the PDFs all look the same.

> >So now the question becomes what do you want to produce these PDFs
> >for, and how are you going to ascertain which browser the consumers
> >are using? If I were sending them to my printers, my expectations
> >(and theirs) would be the sort of copies that I've shown magnified.
> 
> That kind of minutiae doesn't bother me very much (only a
> little...); the big problem is that the lines on the kana row and
> the kanji row are different shapes. They're both three box-drawings
> on each side, but they look quite different in all PDF viewers I've
> tried (Firefox, Chromium, Atril, Okular, xpdf).

Are those characters the same height? I think you should put some
characters into both lines for control purposes; some ordinary Roman
alphabeticals, say.

> Also, I wouldn't say 70kb is much to apologize for.

I meant screen size rather then file size. I usually select the area
of my screenshots (like pasted.png), but I needed to use my
delayed-screenshot button to capture evince's and xpdf's own selection
correctly; you can't drag a mouse to select an area over an already
active mouse selection without destroying the latter.

Cheers,
David.

faulty-at-200.png
Description: PNG image

fine-at-400.png
Description: PNG image