Re: crop marks?

[arnold]

Hi.

Gavin Smith  wrote:

> However, they probably aren't in the right place. I don't really
> understand what the cropmarks are for in the first place. Doesn't it
> depend on what areas of a page a printer is capable of printing on,
> which depends on the printer?

When printing an @smallbook book on regular paper (as an author would
do while working on a book), the pages are (supposed to be) centered
on the larger paper. You can't tell where the physically smaller borders
really are. The cropmarks give you a visual clue as to what the end
result will really be.

> I suspect the code is wrong even for the top crop marks. []
> It all seems very arbitrary to me.

I would think it'd be a straightforward calculation to determine
where to place them, if indeed the @smallbook pages are centered,
or even if they start at the top like regular pages.

I don't doubt that that bit of texinfo.tex is suffering terribly from
bit rot. :-(  Maybe Karl can help?

Thanks for looking into this.  It's not at all urgent, but it'd be
nice if it got attended to sometime in the next months.

Much thanks,

Arnold

Re: crop marks?

[Gavin Smith]

Commenting out one line in texinfo.tex makes the bottom cropmarks visible:

Index: texinfo.tex
===
--- texinfo.tex (revision 8191)
+++ texinfo.tex (working copy)
@@ -418,7 +418,7 @@
   \ifcropmarks
   \egroup % end of \vbox\bgroup
 \hfil\egroup % end of (centering) \line\bgroup
-\vskip\topandbottommargin plus1fill minus1fill
+%\vskip\topandbottommargin plus1fill minus1fill
 \boxmaxdepth = \cornerthick
 \vbox to0pt{\vss
   \line{%

However, they probably aren't in the right place. I don't really
understand what the cropmarks are for in the first place. Doesn't it
depend on what areas of a page a printer is capable of printing on,
which depends on the printer?

I suspect the code is wrong even for the top crop marks. So that the
crop marks are above the heading line with the page numbers, the crop
marks are printed \topandbottommargin - hardcoded as .75 in - above
the start of the main part of the page, below the page numbers. The
heading line itself is hardcoded as 22.5 pt (less than .75 in) above
the start of the main part of the page. It all seems very arbitrary to
me.
On Mon, Nov 19, 2018 at 6:56 PM  wrote:
>
> Gavin Smith  wrote:
>
> > On Tue, Nov 13, 2018 at 07:56:39AM -0700, arn...@skeeve.com wrote:
> > > Once upon a time there was an @cropmarks command in texinfo.tex that
> > > put cropmarks in the corners of the page.  This was particularly helpful
> > > for working with @smallbook in order to visualize what would actually
> > > come back if a book was printed and bound.
> > >
> > > The command seems to still be there but I only get the cropmarks
> > > on the top of the page.
> > >
> > > I'm fairly sure this is an undocumented feature, but if it could be
> > > restored to working order sometime soon, I'd appreciate it.
> >
> > Can you tell me when it worked properly? I tried with various versions of
> > Texinfo. As far back as Texinfo 4.5 I only got the top cropmarks. I
> > tried with Texinfo 3.12 and I do get the bottom cropmarks, but they look
> > like they are in the wrong place unless @smallbook is also given.
>
> Oh lordy. It's been *years*. And indeed they may only have worked
> correctly with @smallbook --- that sounds right. I would be happy if
> that would be restored, since I actually was trying to see what a
> particular document would look like in @smallbook.
>
> I'm starting to think about self-publishing something written in
> Texinfo, which is why I wanted to see what @smallbook looked like.
>
> Much thanks!
>
> Arnold

Re: please migrate to git

[Werner LEMBERG]

> There is "svn blame" which you can use to see when each line in a
> file was changed.

Indeed, but useless for me, since it only shows me existing code while
I'm wanting the opposite :-) I could have done manual bisecting, this
is, checking revision by revision until I find the change.

> I'm happy to upgrade to git now:
> 
> * Works offline
> * More familiar to people
> * Faster

Excellent!

> It will be this weekend at the earliest before I look into making
> this happen.

Thanks.  No rush, please :-)

> 
>> Given that Savannah provides git support and that it is rather easy to
>> import an SVN repository to git (using `git svn ...') I strongly
>> suggest to migrate to git.
> 
> Hopefully it is as simple as running git svn and then uploading the new 
> git repository to Savannah.

Almost, I think.  This guide

  https://aboullaite.me/migration-from-svn-to-gitlab/

looks useful.

Masamichi-san, how did you do the migration?  Maybe Gavin can simply
clone your version, which would be the simplest solution, of course.


Werner

Re: crop marks?

[arnold]

Gavin Smith  wrote:

> On Tue, Nov 13, 2018 at 07:56:39AM -0700, arn...@skeeve.com wrote:
> > Once upon a time there was an @cropmarks command in texinfo.tex that
> > put cropmarks in the corners of the page.  This was particularly helpful
> > for working with @smallbook in order to visualize what would actually
> > come back if a book was printed and bound.
> > 
> > The command seems to still be there but I only get the cropmarks
> > on the top of the page.
> > 
> > I'm fairly sure this is an undocumented feature, but if it could be
> > restored to working order sometime soon, I'd appreciate it.
>
> Can you tell me when it worked properly? I tried with various versions of 
> Texinfo. As far back as Texinfo 4.5 I only got the top cropmarks. I 
> tried with Texinfo 3.12 and I do get the bottom cropmarks, but they look 
> like they are in the wrong place unless @smallbook is also given.

Oh lordy. It's been *years*. And indeed they may only have worked
correctly with @smallbook --- that sounds right. I would be happy if
that would be restored, since I actually was trying to see what a
particular document would look like in @smallbook.

I'm starting to think about self-publishing something written in
Texinfo, which is why I wanted to see what @smallbook looked like.

Much thanks!

Arnold

Re: crop marks?

[Gavin Smith]

On Tue, Nov 13, 2018 at 07:56:39AM -0700, arn...@skeeve.com wrote:
> Once upon a time there was an @cropmarks command in texinfo.tex that
> put cropmarks in the corners of the page.  This was particularly helpful
> for working with @smallbook in order to visualize what would actually
> come back if a book was printed and bound.
> 
> The command seems to still be there but I only get the cropmarks
> on the top of the page.
> 
> I'm fairly sure this is an undocumented feature, but if it could be
> restored to working order sometime soon, I'd appreciate it.

Can you tell me when it worked properly? I tried with various versions of 
Texinfo. As far back as Texinfo 4.5 I only got the top cropmarks. I 
tried with Texinfo 3.12 and I do get the bottom cropmarks, but they look 
like they are in the wrong place unless @smallbook is also given.

Re: my-bib-macros.texi

[Gavin Smith]

On Wed, Oct 17, 2018 at 10:19:25AM -0700, wlharv...@mac.com wrote:
> The utility file my-bib-macros.texi, referenced on the
> Texinfo - The GNU Documentation System https://www.gnu.org/software/texinfo/ 
> 
> has a bug in line 210: 
> 
> (See item [\ref\] in @ref{\node\, \ref\}.)
> 
> The \node\ and the \ref\ are reversed for proper output.  The syntax must have
> changed at some time since 2004.

It's not possible that the syntax will have changed.

> Now, line 210 should read:
> 
> (See item [\ref\] in @ref{\ref\,, \node\}.)

Thank you for the report. I cannot get this file to work at all. Can you 
email me the test file you used?

When I try running the attached file, I get an error message:

$ pdfetex tmp.texi
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
entering extended mode
(./tmp.texi (./texinfo.tex Loading texinfo [version 2018-09-21.20]: pdf,
fonts, markup, glyphs, page headings, tables, conditionals, indexing,
sectioning, toc, environments, defuns, macros, cross references, insertions,
(/usr/share/texmf/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, and turning on texinfo input format.)
(./my-bib-macros.texi) (Top) [1{/usr/share/texmf-var/fonts/map/pdftex/updmap/pd
ftex.map}] Chapter 1 [2]
Cross reference values unknown; you must run TeX again. Chapter 2 [3]
! Argument of @asis has an extra }.
 
@par 
 
   }
@doitemize ...1}@setbox 0 = @hbox {@itemcontents }
  @ifx @itemcontents @empty ...
l.30 @itemize @asis
   
?

Probably there have been changes to texinfo.tex that make my-bib-macros.texi
not work any more.


tmp.texi
Description: TeXInfo document


my-bib-macros.texi
Description: TeXInfo document

Re: please migrate to git

[Gavin Smith]

On Mon, Nov 19, 2018 at 11:27:04AM +0100, Werner LEMBERG wrote:
> while trying to update lilypond's init script from texi2html version
> 1.82 to 5.0 ??? this is what distributions provide today ??? I wanted to
> find out where function `get_index' was changed.  To get all changes
> in the now obsolete texi2html directory I issued the following command
> (I wasn't sure which files to track):
> 
>   cd trunk/texi2html
>   svn log --diff -r "{2009-01-01}:{2018-11-19}" > ~/texi2html.changes
> 
> I started this command more than two hours ago and it is still
> running!  Right now, the commits r2684 (2009-01-01) to r2933
> (2009-11-23) are in the output file, which is currently 306MByte
> large.  In other words, I get approx. two commits per minute with this
> approach.  This is *incredibly* slow!
> 
> Is there a better solution than my naive approach?  Hopefully yes...

There is "svn blame" which you can use to see when each line in a file 
was changed.

> I must admit that I don't know the exaxt reasons why the above command
> is so slow but I guess this is due SVN itself.  I've never experienced
> such a poor performance with git on Savannah (only bzr was similarly
> painful, as Emacs has demonstrated).

I'm happy to upgrade to git now:

* Works offline
* More familiar to people
* Faster

It will be this weekend at the earliest before I look into making this 
happen.

> Given that Savannah provides git support and that it is rather easy to
> import an SVN repository to git (using `git svn ...') I strongly
> suggest to migrate to git.

Hopefully it is as simple as running git svn and then uploading the new 
git repository to Savannah.

Re: please migrate to git

[Norbert Preining]

On Mon, 19 Nov 2018, Masamichi Hosoda wrote:
> No, I update it manually.

I am doing this via cron scripts and Github deploy ssh keys which allows
me to ignore it completely ;-) Also, it helps with CI testing via
Travis-CI.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: please migrate to git

[Masamichi Hosoda]

>> Here is a git mirror I've converted.
>> https://github.com/trueroad/texinfo
> 
> Ahh, great. Is that automatically/regularly updated?

No, I update it manually.

Re: please migrate to git

[Norbert Preining]

On Mon, 19 Nov 2018, Masamichi Hosoda wrote:
> Here is a git mirror I've converted.
> https://github.com/trueroad/texinfo

Ahh, great. Is that automatically/regularly updated?

Thanks a lot

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: please migrate to git

[Masamichi Hosoda]

Hi Werner, Norbert, all

>> Given that Savannah provides git support and that it is rather easy to
>> import an SVN repository to git (using `git svn ...') I strongly
>> suggest to migrate to git.
> 
> If there is interest, I can set up a git svn mirror as I have done for
> luatex, texlive, texlive-source ..., that gets automatically updated.
> Since texinfo is not so big, it could be mirrored into github,
> eg. into the TeX-Live organization, but wherever you prefer.
> 
> The setup I am using is already prepared to mirror other svn repos, too,
> via texlive.info server.

Here is a git mirror I've converted.
https://github.com/trueroad/texinfo

Re: please migrate to git

[Norbert Preining]

Hi Werner, all

>   svn log --diff -r "{2009-01-01}:{2018-11-19}" > ~/texi2html.changes

Umpf, not good. Much faster to do a git svn checkout and then use git.

> Given that Savannah provides git support and that it is rather easy to
> import an SVN repository to git (using `git svn ...') I strongly
> suggest to migrate to git.

If there is interest, I can set up a git svn mirror as I have done for
luatex, texlive, texlive-source ..., that gets automatically updated.
Since texinfo is not so big, it could be mirrored into github,
eg. into the TeX-Live organization, but wherever you prefer.

The setup I am using is already prepared to mirror other svn repos, too,
via texlive.info server.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

please migrate to git

[Werner LEMBERG]

Folks,


while trying to update lilypond's init script from texi2html version
1.82 to 5.0 – this is what distributions provide today – I wanted to
find out where function `get_index' was changed.  To get all changes
in the now obsolete texi2html directory I issued the following command
(I wasn't sure which files to track):

  cd trunk/texi2html
  svn log --diff -r "{2009-01-01}:{2018-11-19}" > ~/texi2html.changes

I started this command more than two hours ago and it is still
running!  Right now, the commits r2684 (2009-01-01) to r2933
(2009-11-23) are in the output file, which is currently 306MByte
large.  In other words, I get approx. two commits per minute with this
approach.  This is *incredibly* slow!

Is there a better solution than my naive approach?  Hopefully yes...

I must admit that I don't know the exaxt reasons why the above command
is so slow but I guess this is due SVN itself.  I've never experienced
such a poor performance with git on Savannah (only bzr was similarly
painful, as Emacs has demonstrated).

Given that Savannah provides git support and that it is rather easy to
import an SVN repository to git (using `git svn ...') I strongly
suggest to migrate to git.


Werner


PS: I know that I should ideally update to texi2any, but this needs a
lot of spare time...