Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2346 > unrolled thread

*nix: pdftotext messes quotes; mouse-pastes OK?

Back to article view | Back to comp.lang.postscript

Contents

  *nix: pdftotext messes quotes; mouse-pastes OK? Unknown <dog@gmail.com> - 2015-09-09 05:34 +0000
    Re: *nix: pdftotext messes quotes; mouse-pastes OK? luser- -droog <mijoryx@yahoo.com> - 2015-09-12 22:18 -0700
      Re: *nix: pdftotext messes quotes; mouse-pastes OK? Unknown <dog@gmail.com> - 2015-09-24 13:27 +0000

#2346 — *nix: pdftotext messes quotes; mouse-pastes OK?

How does mouse-pasting from `xpdf <file.pdf>` manage to do the quote/
apostrophe correctly; when `pdftotext` can't do it: but translates the
single-quote to 3 non-ASCII-chars ?!

I'm guessing, that working backwards from the screen:
screen <-FrameBufrPixels <-Char & Font
Well yes,the mouse current X,Y position is/must be mappable to the 
corresponding char.
Whereas `pdftotext` only sees the bytes of the <File.pdf>.
Ie. the mouse works with wysiwyg, where as `pdftotext` misses out
several translation steps.

Is that right?

[toc] | [next] | [standalone]

#2347

On Wednesday, September 9, 2015 at 12:36:28 AM UTC-5, Unknown wrote:
> How does mouse-pasting from `xpdf <file.pdf>` manage to do the quote/
> apostrophe correctly; when `pdftotext` can't do it: but translates the
> single-quote to 3 non-ASCII-chars ?!
> 
> I'm guessing, that working backwards from the screen:
> screen <-FrameBufrPixels <-Char & Font
> Well yes,the mouse current X,Y position is/must be mappable to the 
> corresponding char.
> Whereas `pdftotext` only sees the bytes of the <File.pdf>.
> Ie. the mouse works with wysiwyg, where as `pdftotext` misses out
> several translation steps.
> 
> Is that right?

Not sure exactly what problem you're encountering, but both programs
"only see the bytes of the file". xpdf is not looking at the pixels.
Even to do things like mouse selection of text, it stores the 
bounding-boxes of strings as it sets them. Then it checks the (x,y)
coordinates of the mouse position against the list of boxes.

There is no "working backwards from the screen". Instead, both
programs work with the encoded representation stored in the pdf 
file. Often this can be a non-standard custom encoding devised just
to store the specific text of the document. If the font is also
embedded, it can be a recoded subset matching the custom encoding
and all information about the source encoding is lost.

It can be the case that a glyph will look the same as an ascii
character but really be some other Unicode code point. In this
case, all gui tools may seamlessly show the same character, but
an ascii-only text editor will show the UTF-8 multi-byte encoding
as several gibberish characters. So it could be it really is a
Right-Single-Quote instead of an ascii single quote, and you're
just not seeing it.

[toc] | [prev] | [next] | [standalone]

#2348

On Sat, 12 Sep 2015 22:18:53 -0700, luser- -droog wrote:

> On Wednesday, September 9, 2015 at 12:36:28 AM UTC-5, Unknown wrote:
>> How does mouse-pasting from `xpdf <file.pdf>` manage to do the quote/
>> apostrophe correctly; when `pdftotext` can't do it: but translates the
>> single-quote to 3 non-ASCII-chars ?!
>> 
>> I'm guessing, that working backwards from the screen: screen
>> <-FrameBufrPixels <-Char & Font Well yes,the mouse current X,Y position
>> is/must be mappable to the corresponding char.
>> Whereas `pdftotext` only sees the bytes of the <File.pdf>. Ie. the
>> mouse works with wysiwyg, where as `pdftotext` misses out several
>> translation steps.
>> 
>> Is that right?
> 
> Not sure exactly what problem you're encountering, but both programs
> "only see the bytes of the file". xpdf is not looking at the pixels.
> Even to do things like mouse selection of text, it stores the
> bounding-boxes of strings as it sets them. Then it checks the (x,y)
> coordinates of the mouse position against the list of boxes.
> 
> There is no "working backwards from the screen". Instead, both programs
> work with the encoded representation stored in the pdf file. Often this
> can be a non-standard custom encoding devised just to store the specific
> text of the document. If the font is also embedded, it can be a recoded
> subset matching the custom encoding and all information about the source
> encoding is lost.
> 
> It can be the case that a glyph will look the same as an ascii character
> but really be some other Unicode code point. In this case, all gui tools
> may seamlessly show the same character, but an ascii-only text editor
> will show the UTF-8 multi-byte encoding as several gibberish characters.
> So it could be it really is a Right-Single-Quote instead of an ascii
> single quote, and you're just not seeing it.

Since I wrote this, I've discovered:
 `pdftotext <option for ASCII> <args>`
which apparently replaces the 3-byte-crap with <singleQuote>.

So then the mouse-pasting does that by default.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web