Where is html formatting for printing done?
Christopher Barker
I was poking into Peppy source with the aim to improve the printing of
plain text files a bit. In particular, I'd like to be able to have text
wrap intelligently.
It looks like the place to do it is in a major mode's:
getHtmlForPrinting() method
However, with some grepping, all I've found is:
./peppy/list_mode.py: def getHtmlForPrinting(self):
./peppy/major.py: def getHtmlForPrinting(self):
./peppy/major_modes/htmlview.py: def getHtmlForPrinting(self):
I'm not interested in listmode, major.py has an empty method for teh
base class, and htmlview jsut dumps the exisitng html.
Where is the one for text mode?
(or the various code modes as well, I might want to tweak that some, too)
And while I'm at it, in text mode, is there an easy way to tell if "text
wrap" is set -- that way I could have the printing match that setting.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Christopher Barker
> Hey Rob,
>
> I was poking into Peppy source with the aim to improve the printing of
> plain text files a bit. In particular, I'd like to be able to have text
> wrap intelligently.
>
> It looks like the place to do it is in a major mode's:
>
> getHtmlForPrinting() method
OK, poking some more, I've found:
And in there, I see, in _drawPageContents():
"""Force the right margin of the rendered window to be huge so the STC
won't attempt word wrapping."""
Ok -- but in my case, I want work wrapping, at least if the mode is set
to word wrapping anyway. But I can't wuite see how to pass the "I want
it to wrap" info in.
Also, maybe for plain text printing, it would be better to just use
HtmlEasyPrinting anyway. would I jsut add a getHtmlForPrinting() method
to text mode for that?
Rob McMullen
<Chris....@noaa.gov> wrote:
> OK, poking some more, I've found:
>
> peppy.lib.stcprint.py
Yep. Sorry for the delay; I was long-windedly answering your other
question. :) Regarding your first email it is controlled in
Fundamental mode. Fundamental is the generic text mode that is based
on the StyledTextCtrl; there is a plain text mode
peppy/major_modes/text.py that is a subclass.
> And in there, I see, in _drawPageContents():
>
> """Force the right margin of the rendered window to be huge so the STC
> won't attempt word wrapping."""
As I remember it, the wx.Rect that you have to use to render in print
coordinates doesn't have any correlation (that I could discover,
anyway) to the coordinates corresponding to the on-screen
representation. My guess was the font metrics for the screen and the
font metrics for the printer are different but aren't reported. I
don't remember exactly, but the log file may prove more interesting:
http://trac.flipturn.org/log/trunk/peppy/lib/stcprint.py
I could never track down the problem, but it's been a year since I've
looked at it.
> Also, maybe for plain text printing, it would be better to just use
> HtmlEasyPrinting anyway. would I jsut add a getHtmlForPrinting() method to
> text mode for that?
To peppy/major_modes/text.py, yep. Maybe that is the best solution
for plain text files. What do you think?
Rob
Christopher Barker
> Yep. Sorry for the delay; I was long-windedly answering your other
> question. :)
no problem -- I'm not expecting instant response!
> Regarding your first email it is controlled in
> Fundamental mode. Fundamental is the generic text mode that is based
> on the StyledTextCtrl; there is a plain text mode
> peppy/major_modes/text.py that is a subclass.
>
>> And in there, I see, in _drawPageContents():
>>
>> """Force the right margin of the rendered window to be huge so the STC
>> won't attempt word wrapping."""
>
> As I remember it, the wx.Rect that you have to use to render in print
> coordinates doesn't have any correlation (that I could discover,
> anyway) to the coordinates corresponding to the on-screen
> representation. My guess was the font metrics for the screen and the
> font metrics for the printer are different but aren't reported. I
> don't remember exactly, but the log file may prove more interesting:
>
> http://trac.flipturn.org/log/trunk/peppy/lib/stcprint.py
hmmm -- I may take a look, but...
> I could never track down the problem, but it's been a year since I've
> looked at it.
>
>> Also, maybe for plain text printing, it would be better to just use
>> HtmlEasyPrinting anyway. would I jsut add a getHtmlForPrinting() method to
>> text mode for that?
>
> To peppy/major_modes/text.py, yep. Maybe that is the best solution
> for plain text files. What do you think?
I think so -- you don't generally want the line numbers and all that for
plain text, though it's nice for code. I'll give it a shot.
As for code, I'm ambivalent about wrapping code, but I think it is
better to wrap it on printing, as long as the line numbers stay correct.
After all, not much point in a print out with stuff truncated.
But for now, I'm going to focus on text.
Rob McMullen
<Chris....@noaa.gov> wrote:
> I think so -- you don't generally want the line numbers and all that for
> plain text, though it's nice for code. I'll give it a shot.
I'm good with with the decision that Text mode has no line numbers
when printed out; and anyway if it's code the goal would be to have a
separate major mode that would use stcprint and contain line numbers.
> As for code, I'm ambivalent about wrapping code, but I think it is better to
> wrap it on printing, as long as the line numbers stay correct. After all,
> not much point in a print out with stuff truncated.
>
> But for now, I'm going to focus on text.
How are you going to turn text into <P>...</P> blocks? Double EOL =
paragraph break, or are you thinking that each EOL should be respected
in itself? I suppose it could depend on how word wrapping was used in
the Text mode instance of the StyledTextCtrl. Or, perhaps a new
preference (in default_classpref) to choose.
Rob
Christopher Barker
> How are you going to turn text into<P>...</P> blocks? Double EOL =
> paragraph break, or are you thinking that each EOL should be respected
> in itself?
yes, both. What I've come up with is pretty simple, but it seems to work
OK for my use cases. I also have two versions:
One for plain text -- it just puts in <p> and <br> and uses the default
font. It works well for general text
I also have a version that uses a fixed width font (<tt>) and puts in
non-breaking spaces for where there are two in a row or more -- this
then works for lining up stuff that has been lined up with spaces. (tabs
will still go to heck!)
What I'm really going for is essentially a <pre> tag, but with wrapping.
The other option, I suppose, is to do fixed width fonts by wrapping by
and and using a <pre> tag, but I'm not sure what width to wrap to.
unfortunately, html doesn't have a "breaking space" element -- which is
what I really want here -- keep the space, but feel free to break on it.
Oh well.
> I suppose it could depend on how word wrapping was used in
> the Text mode instance of the StyledTextCtrl. Or, perhaps a new
> preference (in default_classpref) to choose.
yup -- I wrote a tiny class that holds the two text-to-html methods, so
that we could have a selection method for which was chosen. I'm not sure
how to put that in though, so all I've got now is hard-coded to use the
fixed-width one, which is what I need at the moment.
I've enclosed my text.py major mode file.
Rob McMullen
<Chris....@noaa.gov> wrote:
> yup -- I wrote a tiny class that holds the two text-to-html methods, so that
> we could have a selection method for which was chosen. I'm not sure how to
> put that in though, so all I've got now is hard-coded to use the fixed-width
> one, which is what I need at the moment.
>
> I've enclosed my text.py major mode file.
OK, here's some modifications. I included a classpref to choose the
method of printing and an action that adds a menu item. If I had only
included a classpref, the option would have automatically appeared in
the preferences for TextMode, but with the action you also get a menu
item.
I also added a third method to Text2html that turns consecutive
non-blank lines into a paragraph (i.e. it doesn't respect single EOL
characters).
I'd probably consider refactoring this so instead of 3 methods in
Text2html and a method getConverter that converts an index number into
a method, I'd have 3 separate functions and a dict that maps the index
number to the function. But this is still the design change and I
didn't want to go crazy with it yet.
The classprefs stuff and the PrintStyleSelect are non-obvious, I know,
due to the limited documentation. But hopefully by example they make
some sort of sense.
Rob
Christopher Barker
> OK, here's some modifications. I included a classpref to choose the
> method of printing and an action that adds a menu item. If I had only
> included a classpref, the option would have automatically appeared in
> the preferences for TextMode, but with the action you also get a menu
> item.
OK, I didn't quite follow that, but I can understand the code enough to
mess with it. There was a slight index bug in it.
> I also added a third method to Text2html that turns consecutive
> non-blank lines into a paragraph (i.e. it doesn't respect single EOL
> characters).
I personally don't see a need for that -- as an old TeX guy, I get it,
but it makes a real mess of text files in general.
> I'd probably consider refactoring this so instead of 3 methods in
> Text2html and a method getConverter that converts an index number into
> a method, I'd have 3 separate functions and a dict that maps the index
> number to the function. But this is still the design change and I
> didn't want to go crazy with it yet.
That might be a bit cleaner, yes. I put them all in a class, 'cause I
thought we might some day want some shared state -- like keeping the
font separate from the wrapping, separate from the space-preserving.
> The classprefs stuff and the PrintStyleSelect are non-obvious, I know,
> due to the limited documentation. But hopefully by example they make
> some sort of sense.
yup. I love examples.
Anyway, I've enclosed a version with a couple bug fixes -- while
limited, it works for me and is a MAJOR improvement -- I may never need
TextWrangler again! I say commit it.
Which brings up a point -- how do you use Peppy to work on Peppy? With
the SingleInstanceChecker, I can only run one version, so I can't be
editing with it and testing it at the same time.
Rob McMullen
<Chris....@noaa.gov> wrote:
> On 11/3/10 8:38 PM, Rob McMullen wrote:
>>
>
> OK, I didn't quite follow that, but I can understand the code enough to mess
> with it. There was a slight index bug in it.
Thanks for the index bug fix.
Regarding my confusing paragraph: what I was trying to say is that by
using classprefs, you get (for free) the user interface elements in
the Preferences dialog for that major mode.
It takes the addition of the PrintStyleSelect action to get a menu
item. They both end up using the same classpref setting, but the
Preferences dialog handles it automatically while the action has to
have some explicit coding.
Maybe that didn't help clear the confusion. :)
> That might be a bit cleaner, yes. I put them all in a class, 'cause I
> thought we might some day want some shared state -- like keeping the font
> separate from the wrapping, separate from the space-preserving.
Oh, gotcha. I tend to think in the flyweight pattern and put shared
state stuff into the mode's classprefs; that way preferences can be
saved automatically in the .peppy/preferences.cfg (or
/Users/username/Library/Application Support/Peppy/preferences.cfg on
OS X)
Just looking at the individual methods, I thought they might be useful
on their own. So, I pulled them out of text.py and put them into
peppy/lib/textutil.py.
> Anyway, I've enclosed a version with a couple bug fixes -- while limited, it
> works for me and is a MAJOR improvement -- I may never need TextWrangler
> again! I say commit it.
Committed. I've also been working on a search mode and I'm planning
on releasing a 0.16 shortly. It would be awesome to include an app
bundle, but I'm afraid that cleaning up the build process to get that
to work on the Mac is a big task.
> Which brings up a point -- how do you use Peppy to work on Peppy? With the
> SingleInstanceChecker, I can only run one version, so I can't be editing
> with it and testing it at the same time.
You can get a new instance of peppy that ignores the single instance
restrictions by using the '-t' option on the command line. I suppose
in OS X land, you'd use the app bundle as your main editor and you'd
have to start up a terminal in the peppy source directory and use
'python run.py -t' because you probably don't want to change the app
bundle flags.
Rob
Christopher Barker
> Thanks for the index bug fix.
no problem, you did more work than I did on this!
> Oh, gotcha. I tend to think in the flyweight pattern and put shared
> state stuff into the mode's classprefs; that way preferences can be
> saved automatically in the .peppy/preferences.cfg (or
> /Users/username/Library/Application Support/Peppy/preferences.cfg on
> OS X)
yup -- that makes more sense.
> Just looking at the individual methods, I thought they might be useful
> on their own. So, I pulled them out of text.py and put them into
> peppy/lib/textutil.py.
sounds good.
> Committed.
Cool!
> It would be awesome to include an app
> bundle, but I'm afraid that cleaning up the build process to get that
> to work on the Mac is a big task.
hmmm -- prob me again soon, I don't know when I'll have a chance to work
on it, but I'd like to do it someday.
> You can get a new instance of peppy that ignores the single instance
> restrictions by using the '-t' option on the command line.
cool -- I missed that.
> I suppose
> in OS X land, you'd use the app bundle as your main editor and you'd
> have to start up a terminal in the peppy source directory and use
> 'python run.py -t' because you probably don't want to change the app
> bundle flags.
yup -- that should do it.
Thanks,
Christopher Barker
I found that the default font size in wxHTMLEasyPrinting was kind of
large, at least on my OS-X box.
Rather than just change, that, I took a few minutes to add a menu item
to choose a font size. I put in "small:, medium, large and extra large,
and hard coded those to sizes in the html. If it doesn't work other
systems, we can do something fancier, or just change the hardcoded
items, but it works nicely for me.
Here's a new text.py.
Rob McMullen
<Chris....@noaa.gov> wrote:
> I found that the default font size in wxHTMLEasyPrinting was kind of large,
> at least on my OS-X box.
>
> Rather than just change, that, I took a few minutes to add a menu item to
> choose a font size. I put in "small:, medium, large and extra large, and
> hard coded those to sizes in the html. If it doesn't work other systems, we
> can do something fancier, or just change the hardcoded items, but it works
> nicely for me.
Thanks, your new code works on my system; I had previously in svn
restructured the code into text.py and peppy/lib/textutils.py, so I
shoehorned your mods into those files. I set the default based on the
platform because zero is crazy tiny on linux.
Latest in svn.
Rob
Christopher Barker
What happened to the nifty HTML printing line-wrapping code we had put in?
I've done an svn up, and that feature is gone. I really liked it!
Rob McMullen
<Chris....@noaa.gov> wrote:
> Rob,
>
> What happened to the nifty HTML printing line-wrapping code we had put in?
>
> I've done an svn up, and that feature is gone. I really liked it!
Hmmm, the code is still there and it works on my system. The way we
coded it before was for text mode only. Given what we talked about
recently, are you trying to use it from latex mode?
Rob
Christopher Barker
> <Chris....@noaa.gov> wrote:
>> What happened to the nifty HTML printing line-wrapping code we had put in?
> Hmmm, the code is still there and it works on my system. The way we
> coded it before was for text mode only. Given what we talked about
> recently, are you trying to use it from latex mode?
Now I see the problem -- I don't have a Text mode! I suspect an SVN
merge with my altered code may have borked it.
I'll try to clean that up. If I can't figure it out, I'll be back...
Christopher Barker
> Now I see the problem -- I don't have a Text mode! I suspect an SVN
> merge with my altered code may have borked it.
yup -- I cleaned up my install and all is well.
Thanks,