Your message dated Sat, 17 Sep 2011 04:28:18 -0400
with message-id <[email protected]>
and subject line re: xpdf: Wishlist - drive multiple screens
has caused the Debian Bug report #146337,
regarding xpdf: Wishlist - drive multiple screens
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
146337: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=146337
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: xpdf
Version: 1.00-3
Severity: wishlist
I wrote this email to some hackish friends of mine, and thought I
should also give it back into the xpdf development community.
Technical goal:
A speaker is on one computer, doing a slideshow. The slides appear
on multiple screens across the network. His keypresses for page up
or page down propagate to all these machines so that all the
displays appear to be controlled out of one.
Situations where it can be used:
Example 1: A large conference room has multiple display screens,
each of which has an LCD projector and a computer.
Example 2: Doing slideshows over the network. A student sits at
IGIDR doing a slideshow. I am present over speakerphone. His slides
should display on my screen.
Example 3: A seminar is taking place at a certain venue, and
hundreds of people are hooked in over the Internet, getting a voice
feed in realtime (which is not hard) and getting the slides on their
screen.
Implementation strategy 1: (low level X)
We write a one-to-many exploder working at the X protocol stream
level. So on the master machine, I run something like
$ one2many xpdf slides.pdf
Here one2many gives birth to xpdf. He rigs up things so that xpdf
thinks that HE is the X display server. He copies the X protocol
stream to numerous DISPLAYs.
If we know a bit of X protocol hacking, it should not be hard to
build.
Advantages: The end user only presents a receptive X display server,
he does not have to know anything else.
Disadvantages: A lot of network traffic (though things like lbx can
be used for compressing the protocol stream).
Implementation strategy 2: (hacking inside xpdf)
We open the source code of xpdf and make two versions, master_xpdf
and slave_xpdf. The end-user copies the slideshow and fires it up in
slave_xpdf.
Inside master_xpdf, we modify the event loop to shout about
prevslide/nextslide events to all the slave_xpdfs.
Inside slave_xpdf, we modify the event loop so that he listens to
prevslide/nextslide events from master_xpdf and not from the local
keyboard.
A variant on this is a slave_xpdf which is just an unhacked xpdf,
running under control of something like Don Libes expect(1). Then
the tcl program would listen for master_xpdf over the network, and
feed prevslide/nextslide events to the xpdf running under his control.
Advantage: near-zero network traffic.
Disadvantages: (a) The end-user has to do a wee bit more work -- he
has to first wget a URL and then fire a slave_xpdf on it. (b) We'll
need to merge the source into the xpdf source tree to properly
handle future changes to xpdf.
It'd be great if the xpdf effort can grow into this... :)
-ans.
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux sanna 2.4.17 #2 Sun Feb 10 18:45:12 IST 2002 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages xpdf depends on:
ii xpdf-common 1.00-3 Portable Document Format (PDF) sui
ii xpdf-reader 1.00-3 Portable Document Format (PDF) sui
ii xpdf-utils 1.00-3 Portable Document Format (PDF) sui
--
Ajay Shah [email protected]
Consultant, http://www.mayin.org/~ajayshah
Department of Economic Affairs,
Ministry of Finance, New Delhi
--- End Message ---
--- Begin Message ---
xpdf has had remote capabilities for quite a while now.
--- End Message ---
