[texworks] Current status of Tw development

[Paul A Norman]

Hi,

I would agree that some indication be given on the file menu to the
user that printing from TeXworks is not yet (if ever) supported, and
at that point what about a sub menu offering to open the ( already
typeset document ) in whatever their default pdf viewer is on their
system (possibly utilising and altering Jonathan Kew's script - 26th
January 2010). TW.app.launchFile(TW.target.fileName); may need to
change .ext if this is on the Editor's File menu as well.

 [Are we calling Scirpts from C++ for ver 0.4 ?]

Checking first that there is an already typeset document? And assuming
that their default viewer can print. If there is no default, their
system should prompt them to set one up, or associate the .pdf with
something (that would be OS dependant).

Menu something like?

/File/
 <other File menu items first >
  /Print/
   [sub menu]     /Printing Not Available/  [always greyed]
                        /Open in default Pdf Viewer/ [normal colours -
mouseover: for printing]
                        /Experimental Printing/  [greyed - or normal colours
                                                            for
where/when it is already possible - OS detected]
 <other File menu items ... >

Make /Open in default Viewer/ and /Experimental Printing/ (above)
available if document is typeset, otherwise greyed out.

There is an advantage if some tricky features are not implemented all
at once in all OS-es, for example if Linux gets it first or whatever.

Here, as each Tw release advances, /Experimental Printing/ would be
available to more OS-es. Benefit is that in effect it would be a
staggered or progressive roll out, so if one OS gets it before the
others this becomes a benefit from a development point of view, in
that we are trouble shooting one thing at a time, rather than be
deluged by all sorts of problems relating to specific OS-es and their
sub-releases on a new or enhanced Tw feature..

Final result being that all OS-es have it available --- if it is to be
implemented at all.

I could live with my default pdf viewer handling printing. Just
include details in TeXworks manual as to how to set/change a default
pdf viewer in each main OS.

And perhaps get another possible Print sub menu item in - specifically

      /Open in Acrobat Reader/ [mouseover: if available]

Paul

On 18 November 2010 08:30, Stefan Löffler <st.loeffler at gmail.com> wrote:
> On 2010-11-17 18:41, Bruno Voisin wrote:
>> Le 17 nov. 2010 à 17:48, Stefan Löffler a écrit :
>>
>>> I agree that printing would be nice to have. As would be, e.g.,
>>> continues display in the previewer. Or preview abilities for dvi and ps.
>>> Some people might request that as well (and probably rightly so).
>>> However, none of that is currently available in a state to be put in a
>>> stable release right now (IMHO, at least).
>> That's perfectly fine by me. I'm sorry if you felt my messages as pressure towards adding printing in the upcoming release, that wasn't my purpose. Here I was just reacting to the presentation of TeXworks as just another PDF viewer, as opposed to an integrated TeX GUI. It's perfectly fine that it doesn't include printing yet, or continuous scrolling. Better omit something IMHO than offer it half-baked and inconsistent, it can be added later when it's ready for all platforms. That was the point of my original message: make sure the patch is omitted in official builds if it's not available for all platforms.
>
> No problem :). We're going in the same direction, anyway ;).
>
>>> Well, printing should work on Linux by use of the command line tool lpr.
>>> This may be available on all typical installations, but I don't know for
>>> sure. Besides, its quite old (there are other, more modern systems like
>>> CUPS, but again you need to have it installed, you need a proper
>>> interface, ...) and options (like which pages to print, ...) are device
>>> specific. So it works, but hasn't been tested thoroughly. The same
>>> system would be used on Mac, but if it's typically available there at
>>> all I have no idea.
>>> On Windows, the postscript code is sent to the printer directly if that
>>> is supported.
>> Mac OS X's printing architecture is built on top of CUPS, which has been purchased by Apple a few years back. The command line tool lp is included
>>
>> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/lp.1.html
>
> Thanks, this at least is reassuring.
>
>> There are probably OS X frameworks integrating this with an interface, or maybe Qt does this, but on such areas I must confess my total ignorance.
>
> Well, there is a Qt interface. It can print vector data, provides a nice
> printer settings dialog, etc. What it can't do is render pdf/postscript.
> Poppler, on the other hand, can render pdf, but in the language binding
> we use (poppler-qt4) it can't produce vector data :(. That's how the
> image-printing function was implemented, BTW.
>
> Cheers,
> Stefan
>
>