Hello PageStreamDocs

One note... I just joined the list, so had to forward these messages
to myself to properly respond. That's why this message says that I
wrote the original messages...

On 20-Sep-02, sembazuruplus wrote:
s> --- In PageStreamDocs@y..., Grasshopper Support <support@g...> wrote:

[...]

s> One user (Chris Elliott), has been the first to offer a suggestion as to
s> the initial organization. He got me thinking about this. (Chris, don't be
s> mad at me for posting this publicly!)

No problem, but you could have interleaved your comments into my
message (or, more properly, interleaved the parts of my message
relavent to your comments into your message) for better readability.
But don't get me started on Nettiquitte or I'll start breaking the
rules myself. ;-P

s> This is my thought on the organization. I think working in PageStream
s> documents may actually put to much up front emphasis on the formatting, and
s> less on the content. We would have to break the PageStream document into

But part of the content might be showing the result of an applied
effect. Much easier to have PGS generate it, and then export as .ps or
.pdf for distribution instead of taking a screen grab (especially
since some of the effects only show when saved (or printed) in
postscript... But as mentioned later in this mega-reply (only replying
to 4 messages here...) it might be best to create the base document in
HTML for use as online help, and then (possibly) later have a select
few (or even a program) convert some or all of the HTML into something
that prints as a manual (like PDF) to offer for people to print out.

s> dozens (or hundreds) of individual documents to allow different folks to
s> work on different parts. Also, what may be in a printed manual may be less
s> than the total PageStream knowledge (for example, scripting commands).

I think the scripting commands themselves should be in a printed
manual (and online manual for that matter), but full examples
shouldn't. (Code snippets in the explanation of the commands should be
there though. See any respectable programming manual.)

[...]

s> The only difficult part of the printed manual that is not found in the
s> online docs is the sidebars. I suppose simple tables could take care of
s> that? Another table at the bottom for navigation to next/prev sections,
s> back to the TOC, and other similar sections would be possible to "cut out"
s> later.

Either tables or frames. Pick your poison there, as there are many
people on both sides of the fence (or frame ;-P) there.

s> Of course, the next question is do we start with the current printed manual
s> and create this, or start with the online help? The online help currently
s> includes more information than the printed manual, but I'm not sure if it
s> contains everything in the printed manual.

Well, because HTML is an excellent way to go as a format for online
help, I would suggest flushing out (and correcting) the existing
online help might be the best way to go. Besides, everyone has easy
access to the existing online help (distributed with the package).

I do have a point of contention to make about the online help as it
exists now... Some of the filenames are longer than what the default
Amiga file-system handles. I remember when I installed PGS from the
CD-ROM, I had to then rename some of the help files to their complete
name (referenced from the link). I use PFS3 on my HD which supports
long file names, but during the move from CD-ROM to my HD some of the
filenames were truncated creating broken links. As I remember, the
maximum filename length for Amiga FFS is 32.

[...]

On 20-Sep-02, sembazuruplus wrote:
s> --- In PageStreamDocs@y..., Geoffrey Webb <gwebb@f...> wrote:
s> I have no idea what others use for web-authoring. I make use of
s> Dreamweaver/HomeSite & TextPad for my department's site. HTML templates

I hand code everything. GoldEd (Amiga) provides syntax highlighting to
make my job easier when hand coding. I also have a bias against so
called WYSWYG web authorizer programs. (First: there is no such thing
as WYSWYG in HTML as what the end user sees is based on their browser
and how they have it configured. Second: many of them bloat the code
with extraneous elements that not all browsers can support or silly
things like &nbsp; elements used to try to force centering.)

s> are very handy for this. Since, however, not everyone is even going to
s> want to use one program, possibly a boilerplate of the relevant HTML
s> code could be made available to everyone working on this project. This

This is a good idea. Much like my idea of providing a PGS template
file. We should also agree on a spec level to code to. My suggestion
is pure HTML3.2 as even Amiga browsers support that (though that would
exclude frames as they came in HTML4.0). I'm not sure what level HHV
supports...

s> boilerplate document would allow everyone to work with the same basic
s> HTML page layout & format & since it'd be simple HTML, they could use
s> whatever tools they liked to to work on the code itself. Is there some
s> sort of file repository that this Yahoo! group could use for stashing in
s> work dox?

Yes, there is a file area on Yahoo, as Deron mentions below. See the
Yahoo Groups web site for this mailing list. (Requires you to create a
login for Yahoo for those of you who haven't yet.) See
http://groups.yahoo.com/group/PageStreamDocs for details.

[...]

On 20-Sep-02, sembazuruplus wrote:
s> --- In PageStreamDocs@y..., Grasshopper Support <support@g...> wrote:
s> Yes, we will be able to share files. Either from yahoo, or the
s> grasshopperllc web site.

s> So is the concept of doing it up in HTML first seem the best way? If
s> someone has a better idea, or a reason why this wouldn't work, or would be
s> more difficult than another, I'm interested!

I think HTML seems to be an agreed upon direction. (Or at least that's
what the current round of brainstorming points to.)

On 20-Sep-02, sembazuruplus wrote:
s> --- In PageStreamDocs@y..., Greg Reyna <greyna@e...> wrote:
s> --On Thursday, September 19, 2002 1:48 PM -0500 Grasshopper Support
s> <support@g...> wrote:

s>> Of course, the next question is do we start with the current printed
s>> manual and create this, or start with the online help? The online help
s>> currently includes more information than the printed manual, but I'm not
s>> sure if it contains everything in the printed manual.

s> So the goal of this project is to create both online help, and a printed
s> manual for Pagestream 4.1, right?

Well, if we go with HTML, then the online help would probably be
first, expecially since much is already completed. Why reinvent the
wheel? Conversion from the HTML base document to a printable version
should be possible.

s> It's clear that the pgs4manual.pdf file that's on the website is meant only
s> for printing out since it doesn't contain a table of contents or index. I

It's easy enough to create a TOC in PGS to export to PDF, but it won't
be linkable. Remember, that document was created in PGS, and then
converted to PDF. (Unless Deron adds links capability to PGS for use
in PDF output (and possibly later HTML output). But this isn't the
forum for suggesting features to PGS, just documenting the ones that
exist...)

[...]

s> Is it practical or desirable to design the html doc with a structure that
s> has a one-to-one correspondence with the manual? I mean, for example, to

Well, if the printable manual is derived from the HTML base document
(if that is the way we will eventually go), then I don't see why not.

s> make online page 26 identical to the manual's page 26? I know that this is
s> not normally the way online docs are designed, but if one of the goals is
s> to make a printed manual wouldn't this approach simplify the whole project?

Not to sound rude, but online (or HTML) pages are a silly concept.
Basically, why should the online pages restrict themselves to what can
fit on a printed page when they are really variable length. One would
have to go through several online pages for one topic when all that's
required is a scrollbar on the side of the window. But the order of
sections and topics should be the same. Pagination should only come
into the picture once (if) the conversion to printable is made.

s> Also, if the project worked this way it seems to me that the conversion of
s> the html into a Pagestream doc would be a lot easier. Playing out my

My thought exactly, given the proper software tools.

s> fantasy to the end I imagine that before the conversion, both a table of
s> contents and index could be created so the ease of moving around within the

Actually, this brings up a good point (TOC that is). Deron could
define a TOC, and we fill in the blanks. Someone picks up the Text
frame section of the TOC, and starts writing the copy. If they feel
they need a sub-section that Deron didn't include, they petition him
to add it to the master TOC. (Sounds like we are organizing an open
source programming project... Many of the organizational issues are
the same.) Have the names for each section published somewhere we can
access, and if the Text Frame guy thinks they want to link to another
section they ask the writer of that section for an anchor to link to.

[...]

s> What do you think, does this approach fly? Does it "have wings"?

*FLAP* *FLAP* *FLOP* *FLAP* It's trying to fly. Sorry, It's late
and I'm a bit punch drunk...

Pax
--
Member: Team AMIGA --} WatchDog
Fingerprint: 2C 8A 03 3C D6 D3 32 7F (Chris Elliott)
66 0F 9B 9F 03 77 1D 85 PGP Key ID: A6A79259
Keys (and other stuff) are athttp://www.crosswinds.net/~sembazuru
<tsb>I have made this letter longer than usual because I lack the time to make it shorter. -- Blaise Pascal

Hey there, Chris Elliott

On 20-Sep-02, you wrote:

> Yes, there is a file area on Yahoo, as Deron mentions below.
> See the Yahoo Groups web site for this mailing list. (Requires
> you to create a login for Yahoo for those of you who haven't
> yet.) Seehttp://groups.yahoo.com/group/PageStreamDocs for
> details.

I spent an entire afternoon trying to subscribe to Yahoo groups
a few month ago. Got into a message exchange with the webmaster
and still couldn't get subscribed. They couldn't get my password
to stick on their server. Several passwords for that matter. I
had subscribed twice before and the password didn't stick. I've
given up on them. AWeb-II v3.4. They don't seem to like it,
although I know folks subscribed to some of their groups. Or
maybe they don't like my email address--I dunno, but I'm through
with them.

Regards
--
DAVID L. STEVENS - dstevens@cityscape.net - Springfield, IL USA
TEAM AMIGA - SPUG Computer Club - AMIthlon on Compaq Armada E500 laptop - A3000T-040
#http://cityscape.net/~dstevens/index.htm#

***Software suppliers are trying to make their software packages more
'user-friendly'.... Their best approach, so far, has been to take all
the old brochures, and stamp the words, 'user-friendly' on the cover.
-- Bill Gates***

>s> This is my thought on the organization. I think working in PageStream
>s> documents may actually put to much up front emphasis on the formatting,
>and
>s> less on the content. We would have to break the PageStream document into
>
>But part of the content might be showing the result of an applied
>effect. Much easier to have PGS generate it, and then export as .ps or
>.pdf for distribution instead of taking a screen grab (especially
>since some of the effects only show when saved (or printed) in
>postscript... But as mentioned later in this mega-reply (only replying
>to 4 messages here...) it might be best to create the base document in
>HTML for use as online help, and then (possibly) later have a select
>few (or even a program) convert some or all of the HTML into something
>that prints as a manual (like PDF) to offer for people to print out.

Well, in something that complex, then what we need is the original PS file
(or ILUS) and a scan of the output for onscreen help. I suspect that a
number of the gif files are going to need ilus replacements for decent
document reproduction.

>s> dozens (or hundreds) of individual documents to allow different folks to
>s> work on different parts. Also, what may be in a printed manual may be less
>s> than the total PageStream knowledge (for example, scripting commands).
>
>I think the scripting commands themselves should be in a printed
>manual (and online manual for that matter), but full examples
>shouldn't. (Code snippets in the explanation of the commands should be
>there though. See any respectable programming manual.)

Sounds like I have a volunteer for the scripting section of the manual

>s> The only difficult part of the printed manual that is not found in the
>s> online docs is the sidebars. I suppose simple tables could take care of
>s> that? Another table at the bottom for navigation to next/prev sections,
>s> back to the TOC, and other similar sections would be possible to "cut out"
>s> later.
>
>Either tables or frames. Pick your poison there, as there are many
>people on both sides of the fence (or frame ;-P) there.

Tables is where I landed. The sidebars in the current online help are
integrated into the relevant section of the text, so sticking it into a
single cell table with a border makes it stand out a bit more, and would be
pretty easy to "poach" out when importing into PageStream.

>I do have a point of contention to make about the online help as it
>exists now... Some of the filenames are longer than what the default
>Amiga file-system handles. I remember when I installed PGS from the
>CD-ROM, I had to then rename some of the help files to their complete
>name (referenced from the link). I use PFS3 on my HD which supports
>long file names, but during the move from CD-ROM to my HD some of the
>filenames were truncated creating broken links. As I remember, the
>maximum filename length for Amiga FFS is 32.

OK, I'll try and truncate them to <32 before releasing the new help.

>s> make online page 26 identical to the manual's page 26? I know that
>this is
>s> not normally the way online docs are designed, but if one of the goals is
>s> to make a printed manual wouldn't this approach simplify the whole
>project?
>
>Not to sound rude, but online (or HTML) pages are a silly concept.
>Basically, why should the online pages restrict themselves to what can
>fit on a printed page when they are really variable length. One would
>have to go through several online pages for one topic when all that's
>required is a scrollbar on the side of the window. But the order of
>sections and topics should be the same. Pagination should only come
>into the picture once (if) the conversion to printable is made.

I think the best idea is to stick with the current HTML where basically
logical sections are placed in a single standalone html page. It may be one
or many pages in a PageStream document but that is not a problem.

>s> fantasy to the end I imagine that before the conversion, both a table of
>s> contents and index could be created so the ease of moving around within
>the

Yes, a TOC will be a given since it will be used in the online help to get
to the individual sections.

>Actually, this brings up a good point (TOC that is). Deron could
>define a TOC, and we fill in the blanks. Someone picks up the Text
>frame section of the TOC, and starts writing the copy. If they feel
>they need a sub-section that Deron didn't include, they petition him
>to add it to the master TOC. (Sounds like we are organizing an open
>source programming project... Many of the organizational issues are
>the same.) Have the names for each section published somewhere we can
>access, and if the Text Frame guy thinks they want to link to another
>section they ask the writer of that section for an anchor to link to.

Agreed! I'll put it in me little readme file. In fact, there are already
some "blank" pages that need to be filled in, and I'll try and create the
rest as I notice them. That way the TOC is already flushed out. I'll try
and post a RFC (request for comment) about the proper organization for
documenting some of the features. Like, should Indexing/TOC be documented
in the Text section of the manual?0

>Pax
>--
> Member: Team AMIGA --} WatchDog
>Fingerprint: 2C 8A 03 3C D6 D3 32 7F (Chris Elliott)
> 66 0F 9B 9F 03 77 1D 85 PGP Key ID: A6A79259

Deron Kazmaier - support@grasshopperllc.com
Grasshopper LLC Publishing -http://www.grasshopperllc.com
PageStream DTP for Amiga, Macintosh, and Windows

Hello Grasshopper Support

On 21-Sep-02, Grasshopper Support wrote:

GS>> s> This is my thought on the organization. I think working in PageStream
GS>> s> documents may actually put to much up front emphasis on the formatting,
GS>> and
GS>> s> less on the content. We would have to break the PageStream document into
GS>>
GS>> But part of the content might be showing the result of an applied
GS>> effect. Much easier to have PGS generate it, and then export as .ps or
GS>> .pdf for distribution instead of taking a screen grab (especially
GS>> since some of the effects only show when saved (or printed) in
GS>> postscript... But as mentioned later in this mega-reply (only replying
GS>> to 4 messages here...) it might be best to create the base document in
GS>> HTML for use as online help, and then (possibly) later have a select
GS>> few (or even a program) convert some or all of the HTML into something
GS>> that prints as a manual (like PDF) to offer for people to print out.

GS> Well, in something that complex, then what we need is the original PS file
GS> (or ILUS) and a scan of the output for onscreen help. I suspect that a
GS> number of the gif files are going to need ilus replacements for decent
GS> document reproduction.

I wonder how well Ghostscript, MetaView or Adobe would work for
converting the PS or ILUS to a graphic to remove the losses in quality
inherent in printing then scanning. I guess this is a good place to
ask, what file format should we use for images? My personal preference
is PNG for screen grabs, and JPEG for full color images (like showing
the effects of the image processing commands).

GS>> s> dozens (or hundreds) of individual documents to allow different folks to
GS>> s> work on different parts. Also, what may be in a printed manual may be less
GS>> s> than the total PageStream knowledge (for example, scripting commands).
GS>>
GS>> I think the scripting commands themselves should be in a printed
GS>> manual (and online manual for that matter), but full examples
GS>> shouldn't. (Code snippets in the explanation of the commands should be
GS>> there though. See any respectable programming manual.)

GS> Sounds like I have a volunteer for the scripting section of the manual

Me and my big mouth. ;-/ Well, I guess I should be able to do
something for the ARexx side of the scripting, but I have _no_ idea
about the scripting on Win or MAC. I'm guessing that the general
commands work the same, but I don't know what the mechanisms are for
sending and recieving information, or the basic structure of those
scripts. (Sounds like I should start converting my FinalWriter barcode
script to PGS to get some experience with specifying graphics
placements and grouping. I can also talk to the author of FWCalender
since that is supposed to work in both FW and PGS for ideas and
possible permission to use code snippits in the manual.)

GS>> s> The only difficult part of the printed manual that is not found in the
GS>> s> online docs is the sidebars. I suppose simple tables could take care of
GS>> s> that? Another table at the bottom for navigation to next/prev sections,
GS>> s> back to the TOC, and other similar sections would be possible to "cut out"
GS>> s> later.
GS>>
GS>> Either tables or frames. Pick your poison there, as there are many
GS>> people on both sides of the fence (or frame ;-P) there.

GS> Tables is where I landed. The sidebars in the current online help are
GS> integrated into the relevant section of the text, so sticking it into a
GS> single cell table with a border makes it stand out a bit more, and would be
GS> pretty easy to "poach" out when importing into PageStream.

Makes sense to me. And as I mentioned later in my replied to reply, if
we decided to stick to HTML3.2 frames aren't available. (Does HHV
even handle frames?)

[...]

GS>> Actually, this brings up a good point (TOC that is). Deron could
GS>> define a TOC, and we fill in the blanks. Someone picks up the Text

[...]

GS> Agreed! I'll put it in me little readme file. In fact, there are already
GS> some "blank" pages that need to be filled in, and I'll try and create the

Actually, quite a while ago I had folded your email explanation of the
Layers pallete into the empty framework of the existing
pgs.inttoc.layerpalette.html file. I also cut small images out of a
screen grab for illustrations of what the buttons look like.
Unfortunately I didn't properly back my efforts up outside of the
pagestream tree and an update wiped out all my efforts.

GS> rest as I notice them. That way the TOC is already flushed out. I'll try

That's what I was figuring. (That means less work for you in the short
term so you can continue to pound your head against a brick wall
trying to figure out what happened to the MAC version. ;-P )

GS> and post a RFC (request for comment) about the proper organization for
GS> documenting some of the features. Like, should Indexing/TOC be documented
GS> in the Text section of the manual?0

Pax
--
Member: Team AMIGA --} WatchDog
Fingerprint: 2C 8A 03 3C D6 D3 32 7F (Chris Elliott)
66 0F 9B 9F 03 77 1D 85 PGP Key ID: A6A79259
Keys (and other stuff) are athttp://www.crosswinds.net/~sembazuru
<tsb>Common sense is the collection of prejudices acquired by age eighteen. -- Albert Einstein

Hello Chris Elliott

Replying to myself...

On 25-Sep-02, Chris Elliott wrote:
CE> Hello Grasshopper Support

CE> On 21-Sep-02, Grasshopper Support wrote:

[...]

CE>> Agreed! I'll put it in me little readme file. In fact, there are already
CE>> some "blank" pages that need to be filled in, and I'll try and create the

CE> Actually, quite a while ago I had folded your email explanation of the
CE> Layers pallete into the empty framework of the existing
CE> pgs.inttoc.layerpalette.html file. I also cut small images out of a
CE> screen grab for illustrations of what the buttons look like.
CE> Unfortunately I didn't properly back my efforts up outside of the
CE> pagestream tree and an update wiped out all my efforts.

I found it again. I thought I had attached it to a message in the
PGSSupport list, but wasn't sure. Well, I just checked the archives
and found it attached to message 3934. Here's a direct URL to that
message. (See I was on this project long before it became official.)

http://groups.yahoo.com/group/PageStreamSupport/message/3934

OK, so it's not exactly in the format of a real manual page, but it
has the information there. (I guess I just volunteered to clean it
up.)

Pax
--
Member: Team AMIGA --} WatchDog
Fingerprint: 2C 8A 03 3C D6 D3 32 7F (Chris Elliott)
66 0F 9B 9F 03 77 1D 85 PGP Key ID: A6A79259
Keys (and other stuff) are athttp://www.crosswinds.net/~sembazuru
<tsb>The only thing that stops God from sending another flood is that the first one was useless. -- Chamfort

>GS> Well, in something that complex, then what we need is the original PS
>file
>GS> (or ILUS) and a scan of the output for onscreen help. I suspect that a
>GS> number of the gif files are going to need ilus replacements for decent
>GS> document reproduction.
>
>I wonder how well Ghostscript, MetaView or Adobe would work for
>converting the PS or ILUS to a graphic to remove the losses in quality
>inherent in printing then scanning. I guess this is a good place to
>ask, what file format should we use for images? My personal preference
>is PNG for screen grabs, and JPEG for full color images (like showing
>the effects of the image processing commands).

Does everyone support PNG now? I suppose it is time for PageStream/BME/HHV
to support it, but until then we shouldn't be creating screen shots in it yet!

>GS> Sounds like I have a volunteer for the scripting section of the manual
>
>Me and my big mouth. ;-/ Well, I guess I should be able to do
>something for the ARexx side of the scripting, but I have _no_ idea
>about the scripting on Win or MAC. I'm guessing that the general
>commands work the same, but I don't know what the mechanisms are for
>sending and recieving information, or the basic structure of those
>scripts. (Sounds like I should start converting my FinalWriter barcode
>script to PGS to get some experience with specifying graphics
>placements and grouping. I can also talk to the author of FWCalender
>since that is supposed to work in both FW and PGS for ideas and
>possible permission to use code snippits in the manual.)

For now, just documenting all of the new commands and making sure that the
documentation is correct would be a huge undertaking. In a few weeks I can
cut out all the program command comments (I try and briefly comment the
commands and its parameters in the code) and send them to you. You can
check and make sure they are all there, and that the match (the
documentation is more user-friendly so you can use it as an example for the
new commands). Of course, if it ends up being to big a project, just let us
know! (There, that should keep folks heads ducking below the "radar").

>Makes sense to me. And as I mentioned later in my replied to reply, if
>we decided to stick to HTML3.2 frames aren't available. (Does HHV
>even handle frames?)

No, and it doesn't handle tables either, but I _think_ it ignores tables
and should just pass through the content (ie, it will work to the degree
needed to display these files!)

>GS> Agreed! I'll put it in me little readme file. In fact, there are already
>GS> some "blank" pages that need to be filled in, and I'll try and create the
>
>Actually, quite a while ago I had folded your email explanation of the
>Layers pallete into the empty framework of the existing
>pgs.inttoc.layerpalette.html file. I also cut small images out of a
>screen grab for illustrations of what the buttons look like.
>Unfortunately I didn't properly back my efforts up outside of the
>pagestream tree and an update wiped out all my efforts.

I have it. I think you sent it to me. You included png screen shots
(which Pagemill hates) It was stuck in the TOC, but I've moved it into the
proper spot

Sorry for the delay folks. Wednesday was my birthday, and it kind of drug
into Thursday and then somehow Friday didn't happen <VBG>

>GS> rest as I notice them. That way the TOC is already flushed out. I'll try
>
>That's what I was figuring. (That means less work for you in the short
>term so you can continue to pound your head against a brick wall
>trying to figure out what happened to the MAC version. ;-P )
>
>GS> and post a RFC (request for comment) about the proper organization for
>GS> documenting some of the features. Like, should Indexing/TOC be documented
>GS> in the Text section of the manual?0
>
>(Chris Elliott)

Deron Kazmaier - support@grasshopperllc.com
Grasshopper LLC Publishing -http://www.grasshopperllc.com
PageStream DTP for Amiga, Macintosh, and Windows

Well then... although a bit late.. Congratulations!