lilypond-user
[Top][All Lists]
Advanced

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

Re: Lines to edges of \center-column


From: caagr98
Subject: Re: Lines to edges of \center-column
Date: Sun, 23 Apr 2017 04:12:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

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.

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.

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

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

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



reply via email to

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