How2 wrap 8 text-lines in *.ps?

[NoHtmlMailsPlease]

My final aim is to have adobe's pdf to speech not
make unnatural breaks, because of page-breaks which
don't correspond to paragraph-breaks;
which is what I get when I use openOffice for
text to pdf.

The "hello world" ps-tut doesn't deal with stepping the
y-coordinates down to the next line.

How should I do this, without getting married to ANOTHER
programming language?

==TIA

[Rod Dorman]

In article <j5ifr2$m3c$2...@dont-email.me>,

There isn't any concept of "next line" in PostScript.

Changing the coordinates can be done in more than one way, which
method is used is up the the program that generates the PostScript
program (or the programmer in the case where you're doing it via a
text editor)

--
-- Rod --
rodd(at)polylogics(dot)com

[luser- -droog]

Well, you need to download (or buy) the Adobe books. The Blue
Book is a better tutorial than anything else (and free online),
and the cookbook section has good ideas to get you started.
For the kind of stuff you're describing you certainly will
need to "get married" to postscript, as you say.

The book for what you're trying to do is the Green Book. It
explains how to design the postscript programs that produce
documents. But you won't understand it without having done
the prep work.

While the Red Book (Postscript Language Reference Manual or
PLRM) is available online, the third edition is quite
overwhelming. I strongly recommend to anyone learning
postscript that they buy a first edition manual. It's less
than 1 inch thick! It has the stuff you need. The operator
summary tells you what page to find the details on.
It really is a nice, concise manual.

If any of this fires your imagination, I recommend
Postscript By Example. I'm too sleepy to praise this book
adequately.

[NoHtmlMailsPlease]

"Rod Dorman" <ro...@panix.com> wrote in message
news:j5ildf$cgu$1...@reader1.panix.com...

> In article <j5ifr2$m3c$2...@dont-email.me>,
> NoHtmlMailsPlease <UsePla...@dog.edu> wrote:
>>My final aim is to have adobe's pdf to speech not
>>make unnatural breaks, because of page-breaks which
>>don't correspond to paragraph-breaks;
>>which is what I get when I use openOffice for
>>text to pdf.
>>
>>The "hello world" ps-tut doesn't deal with stepping the
>>y-coordinates down to the next line.
>>
>>How should I do this, without getting married to ANOTHER
>>programming language?
>
> There isn't any concept of "next line" in PostScript.

My brief look at the docus suggests that <newLine> could be programmed as:
/Nline <decr y-coordinate per font size>
<move abs x-coordinate to line-start> def

but I was hoping for a briefer method from here.

[NoHtmlMailsPlease]

"luser- -droog" <mij...@yahoo.com> wrote in message
news:63fea13a-e003-48c6...@g33g2000yqc.googlegroups.com...

Some times I say "I want to speak to the injun-year & not
the sales-clerk ", but let me rather admit how I failed to
see-the-wood-for-the-trees. Since my final aim is only
to NOT have page-breaks in the middle of sentences,
all I needed to do was, use an editor/word-proc, which
can output ps/pdf, and manually <adjust each end of page>.

But the first one which I did this on, & moved it from linux to
Win7 via a stik; the Adobe-dolly said
dot dot dot ....why.

That's "why" as in Y.
Which is strange, since the *.pdf looked perfect under Win7 & linux.

Oh crap!! I've just realised: it's not how the *.pdf LOOKs,
it's whether it can be `pdftoascii -ed`.
Since the failed-to-talk *.pdf was derived from ascii, I'd
expect that to NOT be the problem.

And I'd like to discuss OCR for pdf/ps which won't autoconvert
to ascii, with people who can think-out-of-the-box.

[Rod Dorman]

In article <j5scc5$pak$1...@dont-email.me>,

NoHtmlMailsPlease <UsePla...@dog.edu> wrote:
>"Rod Dorman" <ro...@panix.com> wrote in message
>news:j5ildf$cgu$1...@reader1.panix.com...

>> ...

>> There isn't any concept of "next line" in PostScript.
>
>My brief look at the docus suggests that <newLine> could be programmed as:
>/Nline <decr y-coordinate per font size>
> <move abs x-coordinate to line-start> def

Define what you mean by "per font size". Is that something your
PostScript emitting program is tracking or are you expecting the
PostScript RIP to somehow figure it out for you?

Consider a "line" that starts off with a 16 point high ornamental
character EPS followed by a mix of 12 point Helvetica and 10 point
Palatino-Bold characters.

You'll need to "decr y-coordinate" by at least 16 points (probably a
little more to avoid decenders) before emitting the PostScript code
for that "line".

In PostScript you first position the baseline before drawing the text
which means you have to figure out how tall that line is going to be
before you can do the move.

[no.to...@gmail.com]

In article <j5t5iv$lb7$1...@reader1.panix.com>, ro...@panix.com (Rod Dorman) wrote:

> In article <j5scc5$pak$1...@dont-email.me>,
> NoHtmlMailsPlease <UsePla...@dog.edu> wrote:
> >"Rod Dorman" <ro...@panix.com> wrote in message
> >news:j5ildf$cgu$1...@reader1.panix.com...
> >> ...
> >> There isn't any concept of "next line" in PostScript.
> >
> >My brief look at the docus suggests that <newLine> could be programmed as:
> >/Nline <decr y-coordinate per font size>
> > <move abs x-coordinate to line-start> def
>
> Define what you mean by "per font size". Is that something your
> PostScript emitting program is tracking or are you expecting the
> PostScript RIP to somehow figure it out for you?
>

This thread has become a good example of what happens when
the OP is truncated for economy.
The aim is simply convert plain-text to pdf, for adobe's text-to-speech;
but to control the position of the <page breaks>.
Therefore the <font> is irrelevant.
So AFAICS the algorith is SIMPLY:---
SetConvenientFont
SetConvenientXYstartOfPage
<WriteLineOfAcii>
<NextLine>perConvenientFont
...

> Consider a "line" that starts off with a 16 point high ornamental
> character EPS followed by a mix of 12 point Helvetica and 10 point
> Palatino-Bold characters.
>
> You'll need to "decr y-coordinate" by at least 16 points (probably a
> little more to avoid decenders) before emitting the PostScript code
> for that "line".
>
> In PostScript you first position the baseline before drawing the text
> which means you have to figure out how tall that line is going to be
> before you can do the move.
> --

With the Postscript-priests pretending that their craft is magic,
I was bamboozled into over looking the obvious solution of using
an editor which gives pdf output, and just manually syncronising
page-breaks with para-breaks.

Then I hit the interesting problem of
Linux: ascii to pdf
could be rendered on Win7 abode, but not 'spoken'.
And linux: pdf to ascii
confirmed that pfd2txt(txt2pdf(originalAscii))
[or an alternative notation:
txt2 -> pdf -> txt2]
showed:
"........N"
instead of the original line text.
And the clever adobe-lady spoke:
"dot dot dot dot EN" .

So now the problem has evolve to
'what format does <the linux editor> translate the
original text to pdf, so that it is viewable OK but NOT
translatable back to the original ascii?

Which asks "what pdf formats are there that would
give a ascii to pdf, which didn't translate back to the
original ascii" ?

And even better: has anyone done direct
<text to speech> on Win7?

== TIA

[Robert Bonomi]

In article <j61ffs$33a$1...@dont-email.me>, <no.to...@gmail.com> wrote:
>In article <j5t5iv$lb7$1...@reader1.panix.com>, ro...@panix.com (Rod Dorman) wrote:
>
>> In article <j5scc5$pak$1...@dont-email.me>,
>> NoHtmlMailsPlease <UsePla...@dog.edu> wrote:
>> >"Rod Dorman" <ro...@panix.com> wrote in message
>> >news:j5ildf$cgu$1...@reader1.panix.com...
>> >> ...
>> >> There isn't any concept of "next line" in PostScript.
>> >
>> >My brief look at the docus suggests that <newLine> could be programmed as:
>> >/Nline <decr y-coordinate per font size>
>> > <move abs x-coordinate to line-start> def
>>
>> Define what you mean by "per font size". Is that something your
>> PostScript emitting program is tracking or are you expecting the
>> PostScript RIP to somehow figure it out for you?
>>
>This thread has become a good example of what happens when
>the OP is truncated for economy.
>The aim is simply convert plain-text to pdf, for adobe's text-to-speech;
>but to control the position of the <page breaks>.
>Therefore the <font> is irrelevant.
>So AFAICS the algorith is SIMPLY:---
>SetConvenientFont
>SetConvenientXYstartOfPage
><WriteLineOfAcii>
><NextLine>perConvenientFont

And you were told "PostScript _doesn't_ work that way".
A concept you *still* fail to grasp.

The fact remains that "You don't know what you don't know" and refuse to
listen to any education on the matter, because you "know" you don't need
it.

At a casual glance -- all _I_ am willing to spend on your idiocy -- there
are at least FIVE critical omissions and errors in your algorith[sic].

You have been proven to be 'ineducable', so I won't bother to itemize the
flaws -- it would be a waste of time.

>With the Postscript-priests pretending that their craft is magic,

Nobody claimed it it 'magic', What it is, is a _programming_language_,
that provides a set of _basic_ functionality for the 'general case' of
page layout. *WITHOUT* 'assumptions' about the nature of the page being
laid out.

your '<nextline>' function DOES NOT EXIST -- in the programming language,
that is (although you could _write_ something that doest it) -- *because*
there are an incredible number of 'assumptions' in the behavior _you_
desire and that _cannot_ be made automatically.

Bluntly, _no_ program that allows a user to select, and selectively
apply, different fonts for different parts of a document can use your
simplistic 'newline' logic. In the _special_case_ of an entire document
set in a SINGLE face, size, weight, leading, and orientation, it would
be possible, but _recognizing_ that special case and outputting the
'simpler' code adds un-necessary complexity to the program _creating_
the PostScript. The algorithms in _that_ software to handle the 'general
case' _also_ work on the 'simple' case, so building in "extra" smarts
for the special case is a waste of effort.

>I was bamboozled into over looking the obvious solution of using
>an editor which gives pdf output, and just manually syncronising
>page-breaks with para-breaks.

Chris Glur, as is usual for you, YOU failed to state your 'problem'
properly. You DID get answers to 'what you asked'.

>So now the problem has evolve to
>'what format does <the linux editor> translate the
>original text to pdf, so that it is viewable OK but NOT
>translatable back to the original ascii?

Not a PostScript issue. Ask in a Linux-specific forum, one relevant
to *THAT* editor.

>Which asks "what pdf formats are there that would
>give a ascii to pdf, which didn't translate back to the
>original ascii" ?

Virtually -any- Postscript _can_ have that result. For any of
a _dozen_or_more_ reasons.

>And even better: has anyone done direct
><text to speech> on Win7?

Not a postscript issue.

Therefore, WRONG forum.


>
>== TIA
>

[RedGrittyBrick]

On 23/09/2011 14:11, NoHtmlMailsPlease wrote:
> My final aim is to have adobe's pdf to speech not
> make unnatural breaks, because of page-breaks which
> don't correspond to paragraph-breaks;
> which is what I get when I use openOffice for text to pdf.

There is almost certainly no existing program that creates PDF files
suitably optimised for a specific PDF-to-speech application.


> The "hello world" ps-tut

Perhaps you mean
http://en.wikipedia.org/wiki/PostScript#.22Hello_world.22 or something
very like it.

> doesn't deal with stepping the
> y-coordinates down to the next line.
>
> How should I do this, without getting married to ANOTHER
> programming language?

You can't do this in Postscript without learning the Postscript
programming language to an elementary level of competence.

You could try
http://terpconnect.umd.edu/~zben/PostScript/asciiprint.html but I've no
idea whether it produces PS from which GS can produce PDF from which
your PDF-to-speech application can produce intelligible speech.


If your goal is to convert some existing text to something that is very
well suited to a text-to-speech application, I believe it would be best
to avoid PS or PDF as initial or intermediate formats.

I would evaluate using either plain-text or one of the more common
book-reader formats (e.g. mobi). I believe some models of Kindle can
read books aloud, perhaps their PC "kindle" software also can.

--
RGB