On Tue, Dec 26, 2006 at 21:43 +0100, Frank Küster wrote:
Ralf Stubner [EMAIL PROTECTED] wrote:
I have the impression that it is not a good idea to actually issue a
PostScript command such as 'a4', which is what the 'a4' papersize
definition in config.ps does. Some printers might not like
Ralf Stubner [EMAIL PROTECTED] wrote:
On Tue, Dec 26, 2006 at 21:43 +0100, Frank Küster wrote:
Ralf Stubner [EMAIL PROTECTED] wrote:
I have the impression that it is not a good idea to actually issue a
PostScript command such as 'a4', which is what the 'a4' papersize
definition in
Frank Küster [EMAIL PROTECTED] wrote:
Or wait. We could
- ship our default config.ps in /usr/share/tetex-bin
- in postinst, run the equivalent of the libpaper hook on this file,
creating a temporary file which differs from the default one only by
the papersize setting
- use ucf to
On Mon, Dec 18, 2006 at 09:47 +0100, Frank Küster wrote:
Frank Küster [EMAIL PROTECTED] wrote:
Or wait. We could
- ship our default config.ps in /usr/share/tetex-bin
- in postinst, run the equivalent of the libpaper hook on this file,
creating a temporary file which differs from
Ralf Stubner wrote:
- actually neither 'a4' nor 'letter' as defined in config.ps should not
be used as default paper sizes; one should use A4size or letterSize;
see the end of '4.2 Configuration file paper size command' in the dvips
documentation (texdoc dvips)
The latter point
Ralf Stubner [EMAIL PROTECTED] wrote:
- editing config.ps is non-trivial; there is readymade ed-code in
texconfig for this, though
- maybe one could make use of texconfig for editing the files:
. ship files somewhere in /use/share/$packagename
. copy files to tmpdir in proper TDS
On Mon, Dec 18, 2006 at 12:27 +0100, Frank Küster wrote:
Ralf Stubner [EMAIL PROTECTED] wrote:
- actually neither 'a4' nor 'letter' as defined in config.ps should not
be used as default paper sizes; one should use A4size or letterSize;
see the end of '4.2 Configuration file paper
Ralf Stubner [EMAIL PROTECTED] wrote:
Hm, I'm still unsure this setup will work. No matter whether we set the
default to no or yes, won't that mean that the postinst script
programmatically changes the file (by calling the libpaper hook, and
libpaper will do the same), which is forbidden for
On Sun, Dec 17, 2006 at 14:43 +0100, Frank Küster wrote:
etch_rc_policy.txt sounds differently:
, 3. Configuration files
| Packages must not modify their own or other packages conffiles
| programmatically. (The only correct way to modify a conffile is the
| user running an editor
Except that there are a couple of old bugs in the BTS about that, what
evidence do you have that this issue is actually widely recognized as
a problem? And why the proper solution should be to use libpaper,
instead of teaching users to use geometry.sty or hyperref.sty to include
On Sun, Dec 17, 2006 at 10:19:21PM +0100, Ralf Stubner wrote:
On Sun, Dec 17, 2006 at 14:43 +0100, Frank K?ster wrote:
etch_rc_policy.txt sounds differently:
, 3. Configuration files
| Packages must not modify their own or other packages conffiles
| programmatically. (The only
Julian Gilbey [EMAIL PROTECTED] wrote:
On Sun, Dec 17, 2006 at 10:19:21PM +0100, Ralf Stubner wrote:
On Sun, Dec 17, 2006 at 14:43 +0100, Frank K?ster wrote:
etch_rc_policy.txt sounds differently:
, 3. Configuration files
| Packages must not modify their own or other packages
Stephen Gildea [EMAIL PROTECTED] wrote:
I was motivated to try to fix the paper-size problem for everyone
(well, everyone in the USA) when I was helping a friend who was
totally confused about why his LaTeX document wouldn't print.
Yes, that's the really bad point.
It seems to me that
On Fri, Dec 15, 2006 at 11:34 +0100, Frank Küster wrote:
The approach is flawed, however,
That's what occurred to me too while riding my bike to the
university...
I sometimes think I should spend most of my working hours on my bicycle
with some sort of recording device ... ;-)
Some
On Fri, Dec 15, 2006 at 15:46 +0100, Frank Küster wrote:
Stephen Gildea [EMAIL PROTECTED] wrote:
Tetex should work out of the box; it should not be necessary for a
sysadmin to know to change a /etc/default file.
teTeX does work out of the box, it produces correct paper for those who
Ralf Stubner [EMAIL PROTECTED] wrote:
For dvips I currently see no
possibility to have one configuration file specify another one, that
should also be read.
Will it read multiple config files, e.g. in TEXMFSYSVAR and
TEXMFSYSCONFIG/TEXMFDIST?
I don't now, but I would be
On Fri, Dec 15, 2006 at 08:29 +0100, Frank Küster wrote:
Are you talking about dvipdfm or dvips here?
About dvipdfm. I haven't looked at dvips, and it doesn't make sense if
both behave different.
Ok. I was more concerned with dvips here, having put dvipdfm aside as it
already used
On Thu, Dec 14, 2006 at 22:50 +0100, Frank Küster wrote:
I don't think this is for etch, though, at least not with very thorough
testing in unstable. Should we start a branch, or only do it when we
actually need a further upload targetted at etch?
This is not for etch (at least I hope that
Ralf Stubner [EMAIL PROTECTED] wrote:
On Thu, Dec 14, 2006 at 22:50 +0100, Frank Küster wrote:
I don't think this is for etch, though, at least not with very thorough
testing in unstable. Should we start a branch, or only do it when we
actually need a further upload targetted at etch?
Ralf Stubner [EMAIL PROTECTED] wrote:
I guess the patch to texconfig that you wrote is
the better approach.
The approach is flawed, however,
That's what occurred to me too while riding my bike to the
university...
since it is very easy to construct
situations where files in /etc are
On Fri, Dec 15, 2006 at 10:53:52AM +0100, Ralf Stubner wrote:
The approach is flawed, however, since it is very easy to construct
situations where files in /etc are automatically changed, which we must
not do. Hence it is probably easier to make all files that can be
changed via texconfig
Julian Gilbey [EMAIL PROTECTED] wrote:
Needed documentation: Mention this new mechanism (NEWS.Debian and 'TeX
on Debian'). Explain that it might automatically change configuration
files and explain the consequences, ie, that people should just accept
new upstream versions if they did not make
As we found out, libpaper support didn't work in the old
setup, anyway. So we are not dropping any functionality if we just add
the hook and the file in /etc/default, setting the variable to no
action. We are just adding the possibility to have it done with
libpaper. Why would
Stephen Gildea [EMAIL PROTECTED] wrote:
As we found out, libpaper support didn't work in the old
setup, anyway. So we are not dropping any functionality if we just add
the hook and the file in /etc/default, setting the variable to no
action. We are just adding the possibility to
Frank Küster [EMAIL PROTECTED] wrote:
Second, the files that are affected are currently not configuration
files, which is a bug.
I should point one thing out for Stephen or anyone else reading this bug
report who's not familiar with texconfig: texconfig is already clever
enough to notice
On Thu, Dec 14, 2006 at 08:23 +0100, Frank Küster wrote:
texconfig and therefore the paperconfig hook do *not* control the paper
size that is used for typesetting (i.e. when TeX runs and calculates
where to put the characters relative to the paper origin). It only
takes effect when a
Ralf Stubner [EMAIL PROTECTED] wrote:
First of all, texconfig paper $PAPER only allows letter and a4. So
either we need to change the hook script to check for that - or we patch
texconfig to recognize more paper sizes.
The current limitation is pdftex, which can have it's default papersize
Frank Küster wrote:
The current limitation is pdftex, which can have it's default papersize
changed only by changing pdftexconfig.tex and redumping all formats. The
different pdftexconfig.tex files needed for a4 and letter are hardcoded
into texconfig.
What's the problem? This is the
Ralf Stubner [EMAIL PROTECTED] wrote:
dvipdfm allready links against libpaper.
Err, right. We probably should disable texconfig dvidpdfm paper,
then.
ACK
Hm, no. Actually things are more complicated, and I'm not sure whether
this is a good idea: dvipdfm reads both the libpaper
Frank Küster [EMAIL PROTECTED] wrote:
Ralf Stubner [EMAIL PROTECTED] wrote:
dvipdfm allready links against libpaper.
Err, right. We probably should disable texconfig dvidpdfm paper,
then.
ACK
Hm, no. Actually things are more complicated, and I'm not sure whether
this is a good
On Thu, Dec 14, 2006 at 19:05 +0100, Frank Küster wrote:
Ralf Stubner [EMAIL PROTECTED] wrote:
dvipdfm allready links against libpaper.
Err, right. We probably should disable texconfig dvidpdfm paper,
then.
ACK
Hm, no. Actually things are more complicated, and I'm not sure
On Thu, Dec 14, 2006 at 15:43 +0100, Ralf Stubner wrote:
How about having the original files in TEXMFDIST and change texconfig
such, that it writes the new files to TEXMF(SYS)VAR? That way the user
will not have to deal with the files. But if needed, these files can be
overruled by a file
On Thu, Dec 14, 2006 at 10:50:39PM +0100, Frank K??ster wrote:
Thinking again, I came to the conclusion that it is a bad thing. In
SVN, I have removed the parts of patch-src that add libpaper support to
the dvipdfm binary, instead we will use the patch in this bug report.
After enhancing it
Package: tetex-bin
Version: 3.0-27
Tags: patch
The attached patch solves the widely-recognized problem that tetex
does not obey the system's default paper size.
It's a problem when TeX formats documents for the wrong size paper,
because what's wrong isn't obvious to many users. Everybody
clone 402994 -1
reassign -1 texlive-base-bin
thanks
Hi Stephen!
Thanks a lot for the very detaile dbug report. I cloned it for
texlive-base-bin, as we want to have this in texlive, too.
I assume that the same fix will work more or less for texlive, as it
also uses texconfig-sys. I will chekc
Stephen Gildea [EMAIL PROTECTED] wrote:
Package: tetex-bin
Version: 3.0-27
Tags: patch
The attached patch solves the widely-recognized problem that tetex
does not obey the system's default paper size.
Thanks for your work. I think we'll apply it - however I'd like to
point out that there
36 matches
Mail list logo
