On Wed 21 Sep 2016 at 20:37:28 (+0100), Brian wrote:
> On Tue 20 Sep 2016 at 15:08:58 +0100, Brian wrote:
>
> > On Mon 19 Sep 2016 at 22:41:23 -0500, David Wright wrote:
> >
> > > On Sun 18 Sep 2016 at 16:14:37 (-0400), Haines Brown wrote:
> > > > I've begun to experience problems using the mouse to select a passage in
> > > > a PDF displayed with xpdf 3.03-10 in order to paste it elsewhere.
> > > >
> > > > The ends of lines are truncated to varying degrees. For example in a
> > > > PDF with this:
> > > >
> > > > 123456789
> > > > 123456789
> > > > 1234567
> > > >
> > > > The past might look like
> > > >
> > > > 12345678
> > > > 1234567
> > > > 123456
> > >
> > > Can you confirm that dragging your mouse produces a black rectangle,
> > > and that the rectangle has the last digits (the ones that get lost)
> > > highlighted thus.
> >
> > Could be a possible cause. My mouse skills aren't brilliant and not
> > precisely positioning the rectangle has often lead to my having to redo
> > the copying.
>
> The OP appears to have totally lost interest in his own question and the
> reponses to it but the ins and outs of copying from a PDF get more
> intriguing.
>
> I own up to being quite cavalier in dragging the mouse to produce a
> black rectangle to be copied. The positioning of *all* sides of the
> rectangle in mupdf seems somewhat critical, however.
Ditto, but I don't attempt any precision with the mouse (unlike using
scrot, for example); I just grab a large chuck and then sort it all
out in an emacs buffer.
> I have a PDF which on the screen displays
>
> If You Hear <symbol for a musical quaver note>
> <symbol for a musical quaver note> means that the command you have entered
> has been recognised as being valid (correct),
> i.e. you entered # 0 *
>
> If I postition the black rectangle to just about cover what is on the
> screen (or a little bit less at top and bottom) the text copies as
>
> If You Hear e
> e means that the command you have entered has been recognised as being
> valid (correct),
> i.e. you entered # 0 ..
>
> (The font for the musical note is embedded in the PDF but has no
> ToUnicode map. It comes up as "e").
>
> If the lower boundary is a smidgeon (5 or so pixels) down it picks up
> the following line too. That, of course, doesn't explain the OP's
> observation but it does not appear we are going to progress beyond that
> initial post.
>
> If You Hear e
> e means that the command you have entered has been recognised as being
> valid (correct),
> i.e. you entered # 0 ..
> If You Hear ee
>
> ("ee" is two quavers).
For xpdf, my experience is similar. I assume you're lifting text that
happens to have musical glyphs in it. I lift text from actual music,
and the text is usable. However, any Unicode characters are displayed
as the individual bytes making them up. The music produces mainly
blanks with odd characters in it, usually Unicode bytes or control
characters.
> The line by line selection by evince appears to be less error-prone in
> terms of text copying.
Lifting the text from the same music in evince, it's almost impossible
to select more than one line without the selection expanding uncontrollably.
The result, when pasted, is short lines of fragments of text in
random order: completely unusable. In Unicode, however.
Mupdf is no better: usually a single syllable to each line, with lots
of ? lines respresenting the music. Unicode again. I haven't tried
being selective with the rectangle, just taking the lot.
(The music in question is LilyPond output.)
Cheers,
David.
