Neil Hodgson wrote:
Julian Herten-Greaven:
As for being more trouble than it's worth.. well.. I'm not sure what to say.
I realize I'm new here.. and not in much of a position to request features
or functionality especially given that I'd have trouble getting the work
done myself, but from a strictly objective POV, giving a page number without
a counter-balance tends to cast a shadow on the page number feature.
Well, drop a large printout on the floor, and see if this is useful... :-P
I was fully aware of the need of a total number of pages, and the issues
to get it. Even if at the time, I think we hadn't yet wrapping, so it
was easier: since Scintilla still has fixed height lines, just do a dry
run of a page, and see how many lines fit in. With wrapping, the problem
is even harder.
The work has to be done by someone and that includes deciding on a
sensible implementation. A dry run may require significant processing
time which is only required if the user wants the number of pages
although it would also allow filling in the maximum page number for
the print dialog. On open source projects features and documentation
are written either by people who need the feature or are interested in
that area. Very little code is written because it is a good idea or
will help users. IIRC, Philippe wrote the higher level printing code
like the header and footer and it looks like he wanted to include page
numbers.
Exactly: I found plain printing quite ugly and uninformative, so I added
informations like date of file and filename.
On a similar note, which variables are available for the header/footer?
The only information I have is what is in the documentation for
print.header.format and print.footer.format.
And everything is already used in the default header and footers...
BTW, Neil, you may want to suppress the long dashes — from the
statusbar.text.4, print.header.format and print.footer.format.
These are in the "shadow" part of the Windows Ansi coding, and Pango
doesn't like them. I had a similar char in the statusbar.text.1, and
Pango was complaining on each keystroke about incorrect UTF-8 chars...
Back to printing, indeed I would like to have done more work, but I
didn't felt it was worth the time spent on it vs. the number of times I
use the printing feature...
It would be nice to have central and right aligned parts of the header
and footer, but it needs some computations on string length and some
parsing of the header/footer properties, with special char as separator.
I would like to have print preview, but this is far for obvious to
implement, unless you use MFC...
It would be nice to have separate styles for printing: one may like less
background colors, but more serif fonts, for example.
Now, we have to remember that SciTE is nice and light, and we don't
necessarily want to bloat it with features rarely used.
As Kein-Hong points out, exporting the file and printing it with a more
sophisticated program may be a solution for the occasionnal printing.
Note: don't forget the other export formats: RTF or PDF or even LaTeX.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
_______________________________________________
Scite-interest mailing list
Scite-interest@lyra.org
http://mailman.lyra.org/mailman/listinfo/scite-interest
