LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Heiko Oberdiek <[log in to unmask]>
Sun, 1 Oct 2000 19:58:36 +0200
text/plain (111 lines)
At 21:32 28.09.2000 +0200, Hans Aberg wrote:
>It appears to me that the "hyperref" package ought to appear in the
>"required" part of the LaTeX distribution:

You are right in the importance of the "hyperref" package,
but there are a lot of things that prevent this step at
present. Sebastian has meantioned the main reason:

At 00:27 29.09.2000 +0100, Sebastian Rahtz wrote:

>I think its more fundamental than that, as discussed as far back as
>1993 - hyperref does not fit into the model of LaTeX properly, and
>rides roigh-shod over LaTeX innards when it feels like it. To add it
>to "required" would imply that the kernel team felt that it reliably
>collaborated with kernel packages, which would simply be untrue.

For example the "required" "color" package is well
supported by a lot of hooks in the LaTeX kernel:
  \color@begingroup, \color@endgroup,
  \normalcolor, \set@color, \color@setgroup,
  \color@hbox, \color@vbox, \color@endbox
I found this commands 45 times in "latex.ltx",
not counting the default definitions.

Package "hyperref" would need a lot of more hooks, eg:
* At the beginning of every page it wants to make
  a hyper anchor (\AtBeginDvi problem).
* An official mechanism to extend the arguments
  that are used internally with \label and \ref:
  LaTeX uses two parameters, the formatted counter
  and the page number.  Package "hyperref"/"nameref"
  adds three additional informations like the
  anchor name or the title of a sectioning command.
* The figure model does not fit "hyperref"'s needs:
  Currently the anchor of the figure is made in the
  caption.  But the caption is below the figure in
  most cases, so that if the user follows a link
  to a figure, he would jump below the figure and
  have to scroll in order to see the whole figure.
    Therefore the hyper anchor should be made at
  the beginning of the figure, for the anchor name
  the value of the figure counter of the next
  \caption command has to be known. But LaTeX2e
  allows zero, one, two, ... \caption commands in
  one figure environment. The rest of the hyper
  stuff has to be made at the end of the figure
  to get the whole rectangle.
* Sectioning commands: It is very difficult and risky
  to define these commands, so that the hyper anchor
  is inserted before the sectioning title, but on
  the same page. Currently links to starred
  sectioning commands, followed by \addcontentsline
  point after the sectioning title.
* ...

>To do it right, bits of LaTeX need a rewrite, taking into account the
>needs of hyperref. This is what Context has done, of course,
>integrating the stuff into the kernel.

I see no chance for LaTeX2e, because it is frozen,
and I can understand the LaTeX people, which are
now working on LaTeX3, that they do not want to
rewrite the old LaTeX2e with the risk of introducing
new bugs.

Another reason: unresolved technical problems,
the drivers acts differently:
* In some situations a \leavevmode is executed,
  but not with other drivers.
* The link margins are implemented differently
  (TeX level/PostScript level).
* Some drivers support the "breaklinks" feature,
  other do not.

I think, for a "required" state package "hyperref"
should be more stable, not few bugs have to be
fixed.

The package is in development, so I want
to rewrite the \Read/WriteBookmarks stuff in order
to add additional features (the costs will be
incompatibilities with older versions).

>Also, hyperref should be split into two
>
> a) the package which provides hypertext functionality, acting as a
>    wrapper around driver \specials, and pdftex primitives
>
> b) the package which overrides standard LaTeX commands to add new
>    functionality to them, and interfaces with assorted packages

Yes, a good idea, especially if a) can be made plain
compatible, so that plain formats can benefit from
hyperref (for example graphicx can be used with plain
formats).  It is a hercules task to define and describe
the interfaces and to implement all of this.  So that
cannot be done until tomorrow for persons, which does
not have the strength and power of hercules like me.
Therefore I see it as an aim for the future (I have
already begun to form modules, eg. the \pdfstringdef
module, where the commands are defined together and
marked with the prefix \HyPsd@).

>I am fairly sure Heiko would agree with me on this

Yes, of course, I always agree with Sebastian
(at least in public) :-)

Best regards
  Heiko <[log in to unmask]>

ATOM RSS1 RSS2