PDF Readers

Indeed they would, which explains why - at least some of the time - the word would not be visible in a simple text viewer. Surely, though, if pdf is a "standard", a pdf reader would interpret any of the forms of "hello" you listed above, and be able to show that word on screen.

If you had "hello world", it might continue: moveto 400,450 print space (or however it creates a space) moveto 400,460 print "w" (etc)

If it wrapped to the next line, I guess it would instead continue: moveto 410,100 print "w" (etc)

It would appear that "Find" in the Adobe and Sumatra readers can deal with that change from 400,nnn to 410,nnn while the other readers can't.

Out of interest, I just created two very simple pdfs using xed text editor, with printing to pdf to create a *.pdf. The first had only the word "Test" (saved as test1.pdf). The second had "Test two" as the wording and was saved as test2.pdf. Surprisingly, the first one was

When viewed in Nedit text editor, the files were considerably different, although there were similarities. The words "Test" or "two" did not appear, at least not in that form. There was an awful lot of code in those files for what, at face value, appears to be a very simple text file.

The various pdf readers *do* do that. So what? You are confusing the display function of a pdf reader, which interprets the pdf's contents and displays them to your eye, with a search function, that may or may not be able to find a string that you see with your eye on screen.

And the reason is that with the latter, you are seeking to do something with the raw content of the pdf. That is not the purpose of a pdf reader.

welcome to Postscript, the language created by academics, that forced Apple to put a far more powerful processor with more memory in their printers than in their macintosh computers.

I have no interest in what happens "behind the screen". When I opened a pdf in a text editor it was just out of interest to see if there was recognisable text there. If so, then I would have assumed that was what being searched through using the "find" function. Of course, it might not use that recognisable text even if it was there - it could be searching through something else inherent to the pdf file structure. I don't care if the pdf structure is ASCII, code, bitmap, or Klingon. If the reader shows something on the screen and there's a "find" function I expect it to work, and find *all* instances of whatever I'm searching for.

It may not be the intended /basic/ function, but most readers offer that "find" function. Perhaps the designers of many of those readers simply do know that their "find" function will not find a phrase flowed over two lines.

Then you will be forever ignorant and likely to make idiotic statements.

Your choice

LOL! That explains a lot...

And don't get me started with X-windows. I think that 99% of its commands are never ever used. But they were included in case they were useful, and now we are stuck with it.

The worst people to write ANYTHING are academic computer scientists. They simply cant leave well alone.

Thank Clapton TCP/IP grew organically with features being added as and when they were needed by requests for comment rather than as a top down

Engineers? HP developed a simple way to drive a printer. PCL. Page control language. To make them print postscript took a co-processor and

Engineers want simple stuff that is easy to understand easy to fix and works, even if it isn't Nobel prize complicated.

Postscript is in fact a full blown programming language.

There was a need for *a* standard, Adobes PostScript existed, so it was used, warts and all.

But you are demanding a search function, which involves peeking behind the screen.

Oh, its just a normal hand-wavy ArtStudent? sort of statement. The implication that all that detailed techy stuff is for grease monkeys who are really beneath one's notice. And if ones sanitary towels and lamb fat have blocked the whole streets sewers, why then, that is a fault of the plebs who built it.

What is important is one's feelings, opinions and emotional intelligence and sensitivity, and planet scale ego.

I'm not demanding anything. It's a available function offered in the reader I was using (Qpdfview). I'm sure there are basic readers which don't offer any find function. I wouldn't demand that they offered one; I'd just choose a different reader which had that function. If the function is offered, don't you agree that it should work?

Which of my statements do you consider idiotic?

I have almost no understanding of how any of the programs I use work "behind the screen", whether browser, email, word processor, or indeed pdf reader, and I reckon 99.9% or more of those who use them are the same. Do I have to understand assembly code or whatever to use them? Of course not - no more than anyone has to understand electromagnetic theory to use a power drill.

Of course.

On 05/09/2021 13:18, Jeff Layman wrote: It's a available function offered in the

No.

Once again you are behaving like a spoilt child. It cannot work on all pdfs. Because of what lies under the bonnet of the pdf.

It 'should' work.

Its about as idiotic as my elderly asian neighbour who thinks people are 'inside his computer'

And you have chosen to remain immature ignorant and spoiled. And reject what people who have chosen not to be that way, have to say.

Which is just another symptom of your childishness.

Asking the same question and then stopping up your rears when the answer isn't what you want to hear.

Since PDFs are basically displayable print files, I would expect there to be "hard" line endings that have to be negotiated by the Find function. And then there's the problem of what to do if text appears in columns. Also individual words or letters may have special characteristics such as font size or colour. All this information has to be stripped out for search to work. And what about superscripts and subscripts? Should they be treated the same as normal characters?

I'm not surprised that some PDF search functions don't work very well.

Sometimes it is wiser to be wise than the alternative.

I tend to do research when things don't go as planned and look for an explanation for the failure.

How many transaction packets are required to transfer a single byte of date? It's not very efficient, is it?

That was to do with IP.

Are you suggesting anything more would be incomprehensible to an engineer?

It might be "nice" if it worked in all circs, but the point of pdf and pdf viewers is *not* that, when offered, a search function works correctly on all pdfs, but is rather to provide a means whereby documents created on different platforms by a variety of software can be easily viewed all on platforms. That is all. Anything else is a bonus.

I've noted that search doesn't work as I might like, and I know that this is because what looks like the same pdf can in fact be created, behind the scenes, in a very large number of ways. This is all I know and all I need to know. Just like I know a little, but enough, about how an IC engine works so that I know why, when driving a manual-box car, I need to change gear from time to time, and what conditions (speed, load, slope of road, etc) might be reasons to change gear.

There is a TEXT version of PDF, as well as the more normal BINARY one. The TEXT one is not as clean as one might like, but it does make the information inside the file, easier to view.

In PostScript documents (.ps) you can edit the document pretty much as you like.

In PDF documents, they like to "count stuff", and if a human does edits, it buggers the counter and the counter needs to be corrected. So right away, a tool is needed to "fix up" if you manually edit a text string. PostScript doesn't have nearly the same amount of checks and balances.

The following example is painful/ugly to look at in a PDF viewer, and parts of it were manually edited.

This posting is sent UTF-8, so hopefully the cruft on the second line will copy/paste into a text file OK. The mediabox is not a full sized page of paper.

endobj

endobj

/Contents 4 0 R >>

endobj

stream BT /F1 18 Tf 0 0 Td (Hello World) Tj ET endstream endobj

xref

startxref

The "Hello World" there is easily recognized when "searching" for a text string. A sentence which spans two lines, would never be presented as an unfolded string, and instead appears as two separate ()Tj calls minimum.

(My dog) Tj (ate my homework.) Tj

If I wanted to search for "dog ate", then the extractor has to work extra hard to make sense of what is going on.

I've run into a few documents (produced by some IBM thing), that paint from bottom to top. Thus, if you had an extractor, it cannot "cheat" by assuming the lines paint from top to bottom and that (naturally) "dog ate" is the correct splicing.

And since you can do the equivalent of

(M) Tj (y) Tj ( ) Tj (D) Tj (o) Tj (g) Tj

there are really lots of variations intended to cause heart burn.

PDF allows text to be displayed on a "path", where the path is a spline curve. And the search can sometimes pick that up, if the eventual presentation is (Hello World) Tj along the path. But two strings of the "dog ate" variety on spline curves, would likely not get joined together for a search.

So how ever it works, it is more than a little bit whizzy. If your PDF tool can do "dog ate" in a search, I'd say that is the minimum acceptable capability.

For a Linux user, there is an Acrobat .deb which can load an older version of Linux Acrobat for you. It won't be listed in your package manager (as unsupported or orphan software is removed), but if you need a reference capability, you can install it.

Paul

A quick check on the PDF documents cluttering my desktop, using Adobe Reader (which I almost never-ever use) and PDF-XChange Viewer (which I always use), shows that they seem to find hyphenated onto-the-next-line words OK. It would be interesting to see if only certain readers and documents have a problem - so can anyone point us to an example or two?