Printing htmal pages to paper
Test
a web page (html).
When I make modification to the document I have to make the same modifications to
the html version.
What I would like to do is use the html version as my "main" version and to print
directly from the html page to printer. When I print directly from the html
version it is almost identical to the OpenOffice printed version.
There are a couple of problems though. The OpenOffice document has a lot of "for
more infomation see page nnn" and the html version has links "for more infomation
click here".
What can I do in the html version to make links turn into page numbers when
printed? Som esort of automatic Table of Contents would be gear also. Any
workarounds or tips?
Googling arounn did to turn right pointers.
Jonathan N. Little
http://www.2kevin.net/munging.html
See what Elsa has to say about how you did it:
If this is generated by some script in OpenOffice then maybe you should
ask the OpenOffice group or the maintainers of the script. Otherwise it
would require some post-processing Like a Perl script to parse each
document and extracting the page name from the href's of the links and
add insert them in the text part.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
dorayme
"Jonathan N. Little" <lws...@gmail.com> wrote:
> Maybe you should learn how to properly munge your email address
>
> http://www.2kevin.net/munging.html
>
> See what Elsa has to say about how you did it:
>
> http://invalid.com/
Does Elsa's beauty justify her HTML markup?
--
dorayme
Jonathan N. Little
She thinks it is precious
<!--hppage status="protected"-->
Test
>Test wrote:
>> I am maintaining a 100 OpenOffice document which has been converted using css to
>> a web page (html).
>>
>> When I make modification to the document I have to make the same modifications to
>> the html version.
>>
>> What I would like to do is use the html version as my "main" version and to print
>> directly from the html page to printer. When I print directly from the html
>> version it is almost identical to the OpenOffice printed version.
>>
>> There are a couple of problems though. The OpenOffice document has a lot of "for
>> more infomation see page nnn" and the html version has links "for more infomation
>> click here".
>>
>> What can I do in the html version to make links turn into page numbers when
>> printed? Som esort of automatic Table of Contents would be gear also. Any
>> workarounds or tips?
>
>If this is generated by some script in OpenOffice then maybe you should
>ask the OpenOffice group or the maintainers of the script. Otherwise it
>would require some post-processing Like a Perl script to parse each
>document and extracting the page name from the href's of the links and
>add insert them in the text part.
The html document is not generated by OpenOffice - it is one lengthy html page.
One solution could be that the html file is printed to 100 separate html pages:
page001.htm, page002.htm, etc.. I could then use a small program to look for the
htm� links and turn them into literal page numbers.
I there a tool which I could use to print to separate html pages from one long
html source file?
Andreas Prilop
> There are a couple of problems though. The OpenOffice document has
> a lot of "for more infomation see page nnn" and the html version has
> links "for more infomation click here".
"click here" is really bad.
http://www.w3.org/QA/Tips/noClickHere
Use a separate style sheet for printing:
http://www.htmlhelp.com/reference/css/style-html.html#external
A few ideas for such a print style sheet:
a { color: black ; text-decoration: none }
body { background: white ; color: black ; margin: 0 }
h1 { margin-top: 0 }
.noprint { display: none }
--
In memoriam Alan J. Flavell
http://www.alanflavell.org.uk/charset/
Jonathan N. Little
> On Tue, 1 Dec 2009, Test wrote:
>
>> There are a couple of problems though. The OpenOffice document has
>> a lot of "for more infomation see page nnn" and the html version has
>> links "for more infomation click here".
>
> "click here" is really bad.
> http://www.w3.org/QA/Tips/noClickHere
>
> Use a separate style sheet for printing:
> http://www.htmlhelp.com/reference/css/style-html.html#external
>
> A few ideas for such a print style sheet:
> a { color: black ; text-decoration: none }
> body { background: white ; color: black ; margin: 0 }
> h1 { margin-top: 0 }
> .noprint { display: none }
>
I think what the OP wants is a program to split up one monster HTML
document and automatically adjust all the internal links to their
respective separate pages...Good luck
Adrienne Boswell
writing in news:2sqah59lc815o1iuq...@4ax.com:
One of the problems you are going to face with this is paging. Some
users may want to print on legal paper, and others on letter, which
would change the pagination. So, right off the bat you are doomed to
failure.
--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
Andy Dingley
> When I make modification to the document I have to make the same modifications to
> the html version.
This is fairly common work these days, but still not obvious or
trivial.
> There are a couple of problems though. The OpenOffice document has a lot of "for
> more infomation see page nnn" and the html version has links "for more infomation
> click here".
Some print-only CSS ( "@media print" as a search term), a few classes
of "print-only or no-print" on the HTML and a simple CSS stylesheet
along the lines of @media print { .no-print { display: none; } } can
work wonders here, and very easily. I wish more people used this on
web sites for removing site-nav etc. when printing.
> What can I do in the html version to make links turn into page numbers when
> printed? Som esort of automatic Table of Contents would be gear also. Any
> workarounds or tips?
That's hard. It's not possible (obviously so) to do it from within
individual pages (or chapters), as you need to maintain a current page
count outside this. One way (the way I'd approach it) is to stop
printing the HTML document directly, but instead run it through an
XSLT transform and then print the results. This transform would do a
simple identity copy (search for it) and merely set the page numbers
from being a recognisable field-code into being a printable number for
the document. A simple script (just shell script) loops over all the
documents and sets this in order. If each document is only a single
page, then that's also their page number.
I'd also probably do something more complicated than this, using XSLT
to go from my original document into XSL:FO, then using Apache Fop
(maybe Cocoon, maybe Apache Forrest (Forrest is great for this sort of
document management task)). The reason is that HTML+CSS is intended
for screen use, not printed pages, and it just doesn't have good
support for many features (newspaper columns, page numbering) that are
more relevant to a printed context. XSL:FO is a good solution to all
that, but it's more stuff to learn.
When you're using "HTML" as an editable source format for this sort of
single-source publishing, it's also a good reason to use XHTML instead
of HTML 4. If you don't want to publish to the web as XHTML, it's a
simple XSLT identity copy to transform it into HTML on publication.
Jukka K. Korpela
> I am maintaining a 100 OpenOffice document which has been converted
> using css to a web page (html).
What is "a 100 OpenOffice document", and what is its URL? How was it
converted.
> What I would like to do is use the html version as my "main" version
> and to print directly from the html page to printer.
HTML isn't particularly suitable for that. To begin with, browsers don't do
any automatic hyphenation, which is a normal feature (selectable, of course)
in any decent word processor. On the other hand, keeping HTML format decent
when it is to be routinely generated from a word processor document might be
close to being mission impossible. So what really matters is the relative
importance of print vs. on-screen version
> When I print
> directly from the html version it is almost identical to the
> OpenOffice printed version.
Well, if the words are very short, you might not need hyphenation, but some
day the document will contain supercalifragilisticexpialidocious or
something long like kirjekuorenlipanliimaosankostutuspullonkorkki.
> There are a couple of problems though. The OpenOffice document has a
> lot of "for more infomation see page nnn" and the html version has
> links "for more infomation click here".
The latter is bad practice, see
http://www.cs.tut.fi/~jkorpela/www/click.html
You could use references by names or titles or headings, like
"There is more information about this in section 2.4 Details of
implementation."
And you could make "Details of implementation" a link (turned to look like
normal text on paper, using simple CSS) and "2.4" a separate element that is
hidden on screen (using simple CSS). A reader of the printed version would
need to use the section number rather than page number, but that's probably
tolerable.
> What can I do in the html version to make links turn into page
> numbers when printed? Som esort of automatic Table of Contents would
> be gear also. Any workarounds or tips?
You would need special software for that, possibly something that hasn't
been written yet. And you cannot really control paging when you use HTML and
CSS, so the line numbers would often be wrong.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Chris Beall
(snip)
> What I would like to do is use the html version as my "main" version and to print
> directly from the html page to printer.
And therein lies the problem. HTML browser support for printing (paged
media) is poor at best. IMO you should just modify the Open Office doc
and reconvert it to HTML, unless this is something other than an
automated process.
Chris Beall
Dr J R Stockton
hoo...@188.40.43.213>, Wed, 2 Dec 2009 17:23:22, Adrienne Boswell
<arb...@yahoo.com> posted:
>
>One of the problems you are going to face with this is paging. Some
>users may want to print on legal paper, and others on letter, which
>would change the pagination. So, right off the bat you are doomed to
>failure.
Naive. The OP is posting from EET (GMT+0200) and therefore can be
expected not to be interested in weird American sizes. All normal
applications in Europe, etc., will print on A4 paper.
JavaScript can be programmed to give an automated table of contents, but
I don't know how to deal with page numbering. It could (with effort)
split the document into logical numbered pages of the correct length,
but that leaves the question of ensuring that there is one logical page
on each printed sheet.
But Open Office should have a way of entering an equivalent of Form
Feed, and a way of implementing it in HTML.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Jonathan N. Little
> JavaScript can be programmed to give an automated table of contents, but
> I don't know how to deal with page numbering. It could (with effort)
> split the document into logical numbered pages of the correct length,
> but that leaves the question of ensuring that there is one logical page
> on each printed sheet.
And how will it "know" how many lines per page to split the document up?
It would have to get default font size, but how will is know the users
print margins???
body { margins: 0 } != 0 for the users print margins
Adrienne Boswell
@merlyn.demon.co.uk> writing in
news:NJ5Xs8DE...@invalid.uk.co.demon.merlyn.invalid:
> In comp.infosystems.www.authoring.html message
<Xns9CD55F82F6EC8arbpenya
> hoo...@188.40.43.213>, Wed, 2 Dec 2009 17:23:22, Adrienne Boswell
><arb...@yahoo.com> posted:
>>
>>One of the problems you are going to face with this is paging. Some
>>users may want to print on legal paper, and others on letter, which
>>would change the pagination. So, right off the bat you are doomed to
>>failure.
>
> Naive. The OP is posting from EET (GMT+0200) and therefore can be
> expected not to be interested in weird American sizes. All normal
> applications in Europe, etc., will print on A4 paper.
>
Where the OP is posting from is meaningless - what matters is the user -
the user could be in Europe, or the US, or Japan, or BF Egypt for all we
know.
If the user changes margins, wants/does not want a title or page numbers
printed - all of that will change the printing area, and therefore
pagination.
C A Upsdell
Perhaps the start of a solution: you can use CSS to make some content
appear only when a page is displayed, and other content appear only when
a page is printed. If you can somehow generate both links and page
number references in your document, with CSS classes named (for example)
"no_print" and "no_display" around the appropriate content, you may be
able to achieve your objective.
Anita
news:Pine.LNX.4.64.09...@sarge.rrzn.uni-hannover.de...
> "click here" is really bad.
> http://www.w3.org/QA/Tips/noClickHere
Very cheap semantics argument, plain and simple. There is no difference
whatsoever in the link, only in the language used to refer the user to it.
*Cheap* semantics at that.
dorayme
"Anita" <m...@invalid.com> wrote:
What is particularly semantic, cheap or not, about the idea that it is
better to say "Get <link>" than "blah, blah, <click here>"? If you look
at the url above, you will see that one of the arguments is about not
divulging "too much about the mechanics", hardly an obvious semantic
argument?
There is a general argument to not choose "Click <here> to go to x.com"
over "Go to <x.com>" that might even be described as aesthetic. It is
simpler in that it demonstrates rather than redundantly says things: as
in simply telling a joke and not going on about how this is a joke and
it is so funny.
A clear semantic argument might be to say it is bad to use a heading
element just to get the default bold and sizing for a bit of text when
it is not really a true heading of the order that is pretended (h1, h2,
...)
Btw, whoever said that "click here" is really bad, is wrong. It is just
*generally* not as good as not doing this, it is not *really* bad. I am
reminded of a scene at the beginning of the classic film Dirty Dancing
where one of the sisters complains on arriving with family to a holiday
resort that a disaster has happened, she has forgotten to bring some
item (clothes or shoes or something?). Her father remarks that that is
not a disaster, a disaster is a major earthquake in ...
--
dorayme
John Dunlop
> [Andreas Prilop:]
>
>> "click here" is really bad.
>> http://www.w3.org/QA/Tips/noClickHere
>
> Very cheap semantics argument, plain and simple.
I should hope an author, of all people, would not reject an argument
about semantics out of hand.
> There is no difference whatsoever in the link, only in the language used
> to refer the user to it.
The link text is part of the link. Links have two ends, a destination
anchor and a source anchor. If the source anchor is an A element, its
content, the link text, is part of the link.
> *Cheap* semantics at that.
What is cheap is the fix. The benefit from rewording "click here" exceeds
the effort of doing so.
--
John
Stan Brown
@merlyn.demon.co.uk>:
>
> In comp.infosystems.www.authoring.html message <Xns9CD55F82F6EC8arbpenya
> hoo...@188.40.43.213>, Wed, 2 Dec 2009 17:23:22, Adrienne Boswell
> <arb...@yahoo.com> posted:
> >
> >One of the problems you are going to face with this is paging. Some
> >users may want to print on legal paper, and others on letter, which
> >would change the pagination. So, right off the bat you are doomed to
> >failure.
>
> Naive. The OP is posting from EET (GMT+0200) and therefore can be
> expected not to be interested in weird American sizes. All normal
> applications in Europe, etc., will print on A4 paper.
Lose the snark, Judy. This is the WORLD Wide Web, and someone
creating a European Web site has every reason to expect that it will
be accessed from across the Atlantic.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/2003/05/05/why_we_wont_help_you
Dr J R Stockton
hoo...@85.214.113.135>, Fri, 4 Dec 2009 01:48:37, Adrienne Boswell
<arb...@yahoo.com> posted:
>Gazing into my crystal ball I observed Dr J R Stockton <reply0949
>@merlyn.demon.co.uk> writing in
>news:NJ5Xs8DE...@invalid.uk.co.demon.merlyn.invalid:
>
>> In comp.infosystems.www.authoring.html message
><Xns9CD55F82F6EC8arbpenya
>> hoo...@188.40.43.213>, Wed, 2 Dec 2009 17:23:22, Adrienne Boswell
>><arb...@yahoo.com> posted:
>>>
>>>One of the problems you are going to face with this is paging. Some
>>>users may want to print on legal paper, and others on letter, which
>>>would change the pagination. So, right off the bat you are doomed to
>>>failure.
>>
>> Naive. The OP is posting from EET (GMT+0200) and therefore can be
>> expected not to be interested in weird American sizes. All normal
>> applications in Europe, etc., will print on A4 paper.
>>
>
>Where the OP is posting from is meaningless - what matters is the user -
>the user could be in Europe, or the US, or Japan, or BF Egypt for all we
>know.
>
>If the user changes margins, wants/does not want a title or page numbers
>printed - all of that will change the printing area, and therefore
>pagination.
From the way in which the OP phrased his request, it seems probable that
he wants to print the pages himself. In that case, it will probably be
done on A4, and the margins, etc., may be known and consistent.
You, however, by referring only to legal and letter paper, have failed
to express the possibility that the user might need International
Standard paper sizes. Perhaps there are special models of printer in
the USA which omit provision for or mention of such sizes.
Osmo Saarikumpu
> Btw, whoever said that "click here" is really bad, is wrong. It is just
> *generally* not as good as not doing this, it is not *really* bad.
I guess that it's *really* bad in the sense that it presupposes a device
present that is capable of performing a click.
--
Best wishes,
Osmo
Greg Russell
Osmo Saarikumpu <os...@weppipakki.com> typed:
>> Btw, whoever said that "click here" is really bad, is wrong. It is
>> just *generally* not as good as not doing this, it is not *really*
>> bad.
>
> I guess that it's *really* bad in the sense that it presupposes a
> device present that is capable of performing a click.
Yeah, why the hell would anybody have something that is capable of selecting
an <a ...></a> tag when the html is structured around that?
Something as simple as lynx is capable of it.
Greg Russell
>>> Btw, whoever said that "click here" is really bad, is wrong. It is
>>> just *generally* not as good as not doing this, it is not *really*
>>> bad.
>>
>> I guess that it's *really* bad in the sense that it presupposes a
>> device present that is capable of performing a click.
>
> Yeah, why the hell would anybody have something that is capable of
> selecting an <a ...></a> tag when the html is structured around that?
>
> Something as simple as lynx is capable of it.
... and if that's too complicated for you, I can even deal with the tags
using wget, sed and awk. Whoever stated that the choice of "click here" or
otherwise was cheap semantics was entirely correct.
dorayme
Osmo Saarikumpu <os...@weppipakki.com> wrote:
I have been rethinking this (never use it myself - I don't think!),
perhaps it is *really* bad. Perhaps I was in a special mood at the time
of saying the above?
Not sure I would say it was really bad rather than bad because someone
might not have a clickable device. It would be really bad in a world
where there were no clickable devices or in a world where only a few
folks had them and no one else much knew about them and so did not learn
that click is alternative to whatever most people did to use links (what
would they do in this possible world, cough in a certain way to use
links?)
But I did not take into account users maybe grabbing all the links and
keeping them in some file for themselves for some purpose, click me's
would not be very self explanatory.
Frankly, I have objected to them on aesthetic grounds, on the less is
more principle, something articulated a bit by a bloke called Ockham
many hundreds of years back. Generally people press links when they have
some idea why, so the context surrounding must provide it at least. But
if the context surrounding it does this, then there is no need for the
*extra* click me words since anchor elements can contain appropriate
words from the context.
Now, I can imagine an objection. What if the context was very long and
contained no appropriate words that the anchor tags could wrap? A
context could *possibly* do this, its meaning being incredibly emergent
on its component words, none of which and no continuous sequence of
which would be semantically appropriate for an anchor content.
But I would reply that any author who achieved such a context should
stop the bullshit and get a life and follow simple common practice.
--
dorayme
Dr J R Stockton
8...@news.individual.net>, Sat, 5 Dec 2009 06:01:46, Stan Brown
<the_sta...@fastmail.fm> posted:
>Thu, 3 Dec 2009 18:52:52 +0000 from Dr J R Stockton <reply0949
>@merlyn.demon.co.uk>:
>>
>> In comp.infosystems.www.authoring.html message <Xns9CD55F82F6EC8arbpenya
>> hoo...@188.40.43.213>, Wed, 2 Dec 2009 17:23:22, Adrienne Boswell
>> <arb...@yahoo.com> posted:
>> >
>> >One of the problems you are going to face with this is paging. Some
>> >users may want to print on legal paper, and others on letter, which
>> >would change the pagination. So, right off the bat you are doomed to
>> >failure.
>>
>> Naive. The OP is posting from EET (GMT+0200) and therefore can be
>> expected not to be interested in weird American sizes. All normal
>> applications in Europe, etc., will print on A4 paper.
>
>Lose the snark, Judy. This is the WORLD Wide Web, and someone
>creating a European Web site has every reason to expect that it will
>be accessed from across the Atlantic.
If it is a Web site, which the OP has not said.
Moreover, it is entirely likely that an Eastern European has no interest
in possible readers is strange and distant countries. After all, most
Americans know or care little about the world outside North America.
Perhaps you did not notice that the OP's English, while quite good, has
minor imperfections characteristic of native users of certain North-
Eastern European languages? If he is Finnish, as seems likely, he may
be writing the document in Finnish, which is a language that few non-
Finns can read easily.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Grandson-Of-RFC1036 is published. RFC 5536 Netnews Article Format is a
subset of Internet Message Format which is described in RFC 5532. The
RFCs are read together to determine standard Netnews article format.
Osmo Saarikumpu
>> Osmo Saarikumpu <os...@weppipakki.com> typed:
>> I guess that it's *really* bad in the sense that it presupposes a
>> device present that is capable of performing a click.
> Yeah, why the hell would anybody have something that is capable of selecting
> an <a ...></a> tag when the html is structured around that?
It is not about selecting an a(nchor) element (not tag). Clicking is not
selecting, but activating. E.g., I may select a link with the tabulator
and activate it with the return key.
> Something as simple as lynx is capable of it.
Lynx is a browser, not a device. I'm sure that every browser is capable
of activating a link, but the user may not have or may not be able to
use a device (typically a mouse) capable of clicking.
IOW, at least to me, the use of "click here" implies that navigation is
activated through the mouse in a graphical user interface. It would be
like saying "hit Ctrl + R to refresh the page", which would presuppose a
few things about the users hardware and software.
--
Best wishes,
Osmo