Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

The new www.ctan.org

333 views
Skip to first unread message

CTAN Announcements

unread,
Dec 12, 2012, 4:24:45 AM12/12/12
to ctan...@dante.de, tex...@tex.ac.uk
The CTAN Team is proud to announce the relaunch of the CTAN Web site

http://www.ctan.org/

The new site provides the information and functions of the old site in
a new look&feel. This is a first step towards an improved user
experience. Some of the features of the new site are:

* Informative landing page
* Improved upload form with forwarding to the master hosts
* Browsing of the CTAN tree
* Listing, registering and monitoring of the CTAN mirrors
* Browsing the Catalogue (packages, authors, topics)
* Availability of different skins to suit your taste

Most of the existing URLs are preserved. If you encounter any problems
report them to webmaster -at- ctan.org.

We have established a mailing list for discussions about further
development of the site. Thus all feature requests and proposals
should go there. Register for this mailing list under

https://lists.dante.de/mailman/listinfo/ctanweb


Enjoy the new site and keep on TeXing
The CTAN Team

Marc van Dongen

unread,
Dec 12, 2012, 4:38:14 AM12/12/12
to ctan...@dante.de, tex...@tex.ac.uk
On Wednesday, December 12, 2012 9:24:45 AM UTC, CTAN Announcements wrote:

> http://www.ctan.org/

Congratulations to the CTAN team for a nice job. Congratulations to the TeX user base for an early Christmas present.

Regards,


Marc

Marco Daniel

unread,
Dec 12, 2012, 4:49:40 AM12/12/12
to ctan...@dante.de, tex...@tex.ac.uk
Thanks for the great job. Awesome.

best regards
Marco

Joseph Wright

unread,
Dec 12, 2012, 4:53:18 AM12/12/12
to
On 12/12/2012 09:24, CTAN Announcements wrote:
> The CTAN Team is proud to announce the relaunch of the CTAN Web site
>
> http://www.ctan.org/
>
> The new site provides the information and functions of the old site in
> a new look&feel. This is a first step towards an improved user
> experience.

Looks good: await new features with interest!
--
Joseph Wright

Lars Madsen

unread,
Dec 12, 2012, 8:11:20 AM12/12/12
to
Looks good

/daleif

Ulrike Fischer

unread,
Dec 12, 2012, 8:45:27 AM12/12/12
to
Am Wed, 12 Dec 2012 10:24:45 +0100 (CET) schrieb CTAN Announcements:

> The CTAN Team is proud to announce the relaunch of the CTAN Web site

Until now I was able to search for files and get a listing with the
complete path all in one page. E.g. if I entered "liber" I got a
long list of files and folders with "liber" in their name. This made
it very easy to find a specific file or package.

This functionality seems to have gone: If I enter "liber" I get no
hits (so no lists of files related e.g. to the libertine fonts). And
if I enter some word like "font" I get only hits which links to a
package description.

Is the file search still there? If not I will file a feature
request. I miss it badly ;-(.


--
Ulrike Fischer
http://www.troubleshooting-tex.de/

Gerd Neugebauer

unread,
Dec 12, 2012, 8:51:35 AM12/12/12
to ne...@nililand.de
On Wednesday, December 12, 2012 2:45:27 PM UTC+1, Ulrike Fischer wrote:

> Is the file search still there? If not I will file a feature
>
> request. I miss it badly ;-(.


The file search is not enabled yet. As you can see on the search page some items are grayed out. They contain functionality to be enabled in the future (hopefully).


Ciao
Gerd

Ulrike Fischer

unread,
Dec 12, 2012, 9:03:37 AM12/12/12
to
Am Wed, 12 Dec 2012 05:51:35 -0800 (PST) schrieb Gerd Neugebauer:

>> Is the file search still there? If not I will file a feature

>> request. I miss it badly ;-(.

> The file search is not enabled yet. As you can see on the search
> page some items are grayed out. They contain functionality to be
> enabled in the future (hopefully).

But the gray parts seems to address a search *in* files. That's not
what I meant. I only want to search for file names. E.g. if I input
"ugm" I want as hit "ugm.zip" and "ugmr8a.pfb" etc.

Gerd Neugebauer

unread,
Dec 12, 2012, 9:17:51 AM12/12/12
to ne...@nililand.de
On Wednesday, December 12, 2012 3:03:37 PM UTC+1, Ulrike Fischer wrote:
> Am Wed, 12 Dec 2012 05:51:35 -0800 (PST) schrieb Gerd Neugebauer:
[...]
> > The file search is not enabled yet. As you can see on the search
> > page some items are grayed out. They contain functionality to be
> > enabled in the future (hopefully).
>
>
> But the gray parts seems to address a search *in* files. That's not
> what I meant. I only want to search for file names. E.g. if I input
> "ugm" I want as hit "ugm.zip" and "ugmr8a.pfb" etc.

I got it. It is related to the same mechanism. The indexing needs to traverse the whole directory tree and add entries to the index. This will also record the file names whcih can be sought then.

Ciao
Gerd

Victor Eijkhout

unread,
Dec 12, 2012, 11:46:24 AM12/12/12
to
CTAN Announcements <ctan...@dante.de> wrote:

> The CTAN Team is proud to announce the relaunch of the CTAN Web site

It's one of those unsung web sites. Modest appearance, but it's very
usefull. Thanks for continuing to improve it.

Victor.
--
Victor Eijkhout -- eijkhout at tacc utexas edu

Manuel Collado

unread,
Dec 12, 2012, 11:26:17 AM12/12/12
to
Not exactly the file search, but it seems that the search facility
supports some kind of "wildcards" when searching for package names and
short descriptions.

Please try "liber*". You will get 9 hits.

--
Manuel Collado - http://lml.ls.fi.upm.es/~mcollado

Peter Flynn

unread,
Dec 12, 2012, 3:35:17 PM12/12/12
to
On 12/12/2012 09:24 AM, CTAN Announcements wrote:
> The CTAN Team is proud to announce the relaunch of the CTAN Web site
>
> http://www.ctan.org/

This is excellent. Congratulations to all concerned.

///Peter

Dan

unread,
Dec 12, 2012, 6:15:55 PM12/12/12
to
On Dec 12, 3:24 am, CTAN Announcements <ctan-...@dante.de> wrote:
> The CTAN Team is proud to announce the relaunch of the CTAN Web site
>
>    http://www.ctan.org/
>
> The new site provides the information and functions of the old site in
> a new look&feel.

I actually got to see a preliminary version some months ago. Glad to
see some minor problems corrected. Nice look. But I am not a fan of
the 3D mouse-over effect on buttons. A bit too "look-at-me" for my
taste.


Dan

Lars Madsen

unread,
Dec 13, 2012, 5:42:02 AM12/13/12
to
me too, that is not nice. Color change is fine, but they should not move.

I guess it is a missing css setting, a border that need a default value

/daleif

Gerd Neugebauer

unread,
Dec 13, 2012, 6:44:46 AM12/13/12
to
Your guess is wrong. The movement has been built in conciously by me.

If you don't like it you can choose another skin. I propose you try "plain". This should not disturb you with any fancy effects;-)

> /daleif

Ciao
Gerd

jon

unread,
Dec 13, 2012, 9:21:37 AM12/13/12
to ctan...@dante.de, tex...@tex.ac.uk
On Wednesday, 12 December 2012 04:24:45 UTC-5, CTAN Announcements wrote:
> The CTAN Team is proud to announce the relaunch of the CTAN Web site
> http://www.ctan.org/

thanks to all concerned!

one thing, though, i just tried to download imakeidx.zip from:

http://www.ctan.org/tex-archive/macros/latex/contrib/imakeidx

and it tries to download:

http://ctan.mirror.rafal.ca/macros/latex/contrib/imakeidx.zip/imakeidx.zip

which it can't find, naturally. (this also happened yesterday with the eledmac files.)

cheers,
jon.

Robin Fairbairns

unread,
Dec 13, 2012, 10:38:00 AM12/13/12
to
sorry about that. the bug has been found, but can't be corrected until
this evening (involves re-running the indexing, apparently...).
--
Robin Fairbairns, Cambridge
sorry about all this posting. i'll go back to sleep in a bit.

Dan Luecking

unread,
Dec 13, 2012, 3:28:26 PM12/13/12
to
On Thu, 13 Dec 2012 03:44:46 -0800 (PST), Gerd Neugebauer
<ge...@gerd-neugebauer.de> wrote:

>On Thursday, December 13, 2012 11:42:02 AM UTC+1, Lars Madsen wrote:
>> On 12/13/2012 12:15 AM, Dan wrote:
>> > On Dec 12, 3:24 am, CTAN Announcements <ctan-...@dante.de> wrote:
>> >> The CTAN Team is proud to announce the relaunch of the CTAN Web site
>> >>
>> >> http://www.ctan.org/
>>
>> >> The new site provides the information and functions of the old site in
>> >> a new look&feel.
>>
>> > I actually got to see a preliminary version some months ago. Glad to
>> > see some minor problems corrected. Nice look. But I am not a fan of
>> > the 3D mouse-over effect on buttons. A bit too "look-at-me" for my
>> > taste.
>> >
>> > Dan
>>
>> me too, that is not nice. Color change is fine, but they should not move.
>>
>> I guess it is a missing css setting, a border that need a default value
>
>Your guess is wrong. The movement has been built in conciously by me.

Then at least it shouldn't cause the _rest_ of the page to
move. This is the effect I see when mousing over the [Search]
button on the search page (in both my browsers; this also
happens on the home page, but only in one of them). Lars may
be right: perhaps the css doesn't take into account that the
button takes up more space in its 3d version.

I might add that the text "Options" on the search page is
kind of weird. It doesn't appear clickable (the mouse
pointer becomes a text cursor and there is no color change).
And on first entering the page there is an [X] next to it
that has no effect when clicked except it changes to a
\triangledown. Clicking the triangle has no effect. Only
optimistically clicking on the word "Options" itself
produces a checklist.

>
>If you don't like it you can choose another skin. I propose you try "plain".
>This should not disturb you with any fancy effects;-)

Ah, now I see that you have hidden a "Settings" link up
behind the lion. This seems a too inconspicuous place to
put it. The usual way to read a page is to start at the
title and scan downward. I missed it completely.

Actually the plain skin is not too bad, but that may be
too much of a change. We mostly just don't want our text
jumping around.

One advantage of plain is that the "Settings" and "Help"
links are a little more obvious, being set off in a bar
along the top of the page along with other buttons.


Dan
To reply by email, change LookInSig to luecking

Joris Pinkse

unread,
Dec 13, 2012, 4:49:25 PM12/13/12
to

> Then at least it shouldn't cause the _rest_ of the page to
> move. This is the effect I see when mousing over the [Search]
> button on the search page (in both my browsers; this also
> happens on the home page, but only in one of them). Lars may
> be right: perhaps the css doesn't take into account that the
> button takes up more space in its 3d version.
>

The rest of the page doesn't move for me (Chrome on Ubuntu).

Gerd Neugebauer

unread,
Dec 13, 2012, 5:44:34 PM12/13/12
to
On Thursday, December 13, 2012 9:28:26 PM UTC+1, Dan Luecking wrote:
> On Thu, 13 Dec 2012 03:44:46 -0800 (PST), Gerd Neugebauer
[...]
> >Your guess is wrong. The movement has been built in conciously by me.
>
> Then at least it shouldn't cause the _rest_ of the page to
> move. This is the effect I see when mousing over the [Search]
> button on the search page (in both my browsers; this also
> happens on the home page, but only in one of them). Lars may
> be right: perhaps the css doesn't take into account that the
> button takes up more space in its 3d version.

I have taken this into account. Bothe the mathematics as well as my
observations with several browsers have confirmed this for me.

Which browers (version) under which OS have you used?
... and with which magnification?

> I might add that the text "Options" on the search page is
> kind of weird. It doesn't appear clickable (the mouse
> pointer becomes a text cursor and there is no color change).
> And on first entering the page there is an [X] next to it
> that has no effect when clicked except it changes to a
> \triangledown. Clicking the triangle has no effect. Only
> optimistically clicking on the word "Options" itself
> produces a checklist.

There has been a discssion about that. I will have to fine-tune this.

> >If you don't like it you can choose another skin. I propose you try "plain".
> >This should not disturb you with any fancy effects;-)
>
> Ah, now I see that you have hidden a "Settings" link up
> behind the lion. This seems a too inconspicuous place to
> put it. The usual way to read a page is to start at the
> title and scan downward. I missed it completely.

Usually you should not be disturbed by such noise. It will become more
obvious when the registering and login are activated in the future.

> Actually the plain skin is not too bad, but that may be
> too much of a change. We mostly just don't want our text
> jumping around.

Understandable. I would like to calm down the movement of the rest of
the page without nailing the buttons to the background...

> One advantage of plain is that the "Settings" and "Help"
> links are a little more obvious, being set off in a bar
> along the top of the page along with other buttons.
>
> Dan

Ciao
Gerd

Lee Rudolph

unread,
Dec 13, 2012, 5:50:20 PM12/13/12
to
Gerd Neugebauer <ge...@gerd-neugebauer.de> writes:

>On Thursday, December 13, 2012 9:28:26 PM UTC+1, Dan Luecking wrote:
>> On Thu, 13 Dec 2012 03:44:46 -0800 (PST), Gerd Neugebauer
>[...]
>> >Your guess is wrong. The movement has been built in conciously by me.
>>
>> Then at least it shouldn't cause the _rest_ of the page to
>> move. This is the effect I see when mousing over the [Search]
>> button on the search page (in both my browsers; this also
>> happens on the home page, but only in one of them). Lars may
>> be right: perhaps the css doesn't take into account that the
>> button takes up more space in its 3d version.
>
>I have taken this into account. Bothe the mathematics as well as my
>observations with several browsers have confirmed this for me.
>
>Which browers (version) under which OS have you used?
>... and with which magnification?

It happens for me as well (also for the "Reset Input" button)
using Firefox 17.0.1 on Windows 7 at every available magnification.

On the other hand, it doesn't happen at all with lynx.

Lee Rudolph

Gerd Neugebauer

unread,
Dec 14, 2012, 3:30:20 AM12/14/12
to

On Thursday, December 13, 2012 11:50:20 PM UTC+1, Lee Rudolph wrote:
> Gerd Neugebauer <ge...@gerd-neugebauer.de> writes:
[...]
> >Which browers (version) under which OS have you used?
> >... and with which magnification?
>
> It happens for me as well (also for the "Reset Input" button)
> using Firefox 17.0.1 on Windows 7 at every available magnification.

Strange, I have checked the behaviour on Windows 7 with Firefox
17.0.1 and I do not see this effect at all:-(

> On the other hand, it doesn't happen at all with lynx.
>
> Lee Rudolph

Ciao
Gerd

Ronnie Marksch

unread,
Dec 14, 2012, 3:56:48 AM12/14/12
to
On 12/14/2012 09:30 AM, Gerd Neugebauer wrote:
>
> On Thursday, December 13, 2012 11:50:20 PM UTC+1, Lee Rudolph wrote:
>> Gerd Neugebauer <ge...@gerd-neugebauer.de> writes:
> [...]
>>> Which browers (version) under which OS have you used?
>>> ... and with which magnification?
>>
>> It happens for me as well (also for the "Reset Input" button)
>> using Firefox 17.0.1 on Windows 7 at every available magnification.
>
> Strange, I have checked the behaviour on Windows 7 with Firefox
> 17.0.1 and I do not see this effect at all:-(

http://www.ctan.org/search
I have the effect under (gentoo) linux with:
FF 10.0.11
Midori 0.4.6
Opera 12.11

Even if these versions are not the most current, it should be obvious
that something is wrong (?)

Still, it is a nice makeover!

Manuel Collado

unread,
Dec 14, 2012, 7:50:08 AM12/14/12
to
El 14/12/2012 9:56, Ronnie Marksch escribió:
> On 12/14/2012 09:30 AM, Gerd Neugebauer wrote:
>>...
>> Strange, I have checked the behaviour on Windows 7 with Firefox
>> 17.0.1 and I do not see this effect at all:-(
>
> http://www.ctan.org/search
> I have the effect under (gentoo) linux with:
> FF 10.0.11
> Midori 0.4.6
> Opera 12.11
>
> Even if these versions are not the most current, it should be obvious
> that something is wrong (?)

The content movement for the search webpage in FF 17.0 is triggered just
by the two buttons inside the blue search panel. It is the panel itself
that gets taller, and this cause all page stuff below it to be relocated
accordingly.

Dan

unread,
Dec 14, 2012, 4:29:28 PM12/14/12
to
On Dec 13, 4:44 pm, Gerd Neugebauer <g...@gerd-neugebauer.de> wrote:
> On Thursday, December 13, 2012 9:28:26 PM UTC+1, Dan Luecking wrote:
> > On Thu, 13 Dec 2012 03:44:46 -0800 (PST), Gerd Neugebauer
> [...]
> > >Your guess is wrong. The movement has been built in conciously by me.
>
> > Then at least it shouldn't cause the _rest_ of the page to
> > move. This is the effect I see when mousing over the [Search]
> > button on the search page (in both my browsers; this also
> > happens on the home page, but only in one of them). Lars may
> > be right: perhaps the css doesn't take into account that the
> > button takes up more space in its 3d version.
>
> I have taken this into account. Bothe the mathematics as well as my
> observations with several browsers have confirmed this for me.
>
> Which browers (version) under which OS have you used?
> ... and with which magnification?

Versions:

Windows 7 Enterprise:
Firefox 17.0.1
Chrome (don't know the version, it's on my work computer. Only this
one
shows motion of other text on home page.)

Widows 7 Home premium:
Firefox 17.0.1
Opera 12.11

Magnification:
All tested magnifications except that, in all three browsers, the
effect
disappears when the "Search" and "Reset input" buttons become
stacked
one atop the other.

Firefox won't tell me what the magnification is, but the disappearance
occurs after after three presses of Ctrl-+ from the default. Perhaps
130%, assuming 100% is default and steps are 10%?

I can't test Chrome at the moment, but it was a similar number of
steps
above default.

In Opera the effect disappears at 140%. (4 steps above default.)


Dan

Gerd Neugebauer

unread,
Dec 14, 2012, 5:29:28 PM12/14/12
to
On Friday, December 14, 2012 10:29:28 PM UTC+1, Dan wrote:
[...]
> Versions:
> Windows 7 Enterprise:
> Firefox 17.0.1
> Chrome (don't know the version, it's on my work computer. Only this
> one
> shows motion of other text on home page.)
>
> Widows 7 Home premium:
> Firefox 17.0.1
> Opera 12.11
>
> Magnification:
> All tested magnifications except that, in all three browsers, the
> effect
> disappears when the "Search" and "Reset input" buttons become
> stacked
> one atop the other.

[...]

OK. I got it. The issue should be fixed now.

Thanks for all who pointed me to this flaw.

Gerd

Jim Diamond

unread,
Dec 15, 2012, 12:15:51 PM12/15/12
to
Amusingly, I didn't have motion before when I moused over the button,
now I do. So it is just broken in a different way.

Firefox 17.0.1 on Slackware64 14.0, default magnification.

Cheers.
Jim

Herbert Schulz

unread,
Dec 15, 2012, 12:24:16 PM12/15/12
to
In article <slrnkcpc27.c9...@jdiamond-nb2.acadiau.ca>,
Howdy,

Same is true here using Safari under OS X. No problem before and text
movement now.

Good Luck,
Herb Schulz

Gerd Neugebauer

unread,
Dec 17, 2012, 6:16:51 PM12/17/12
to
On Saturday, December 15, 2012 6:24:16 PM UTC+1, Herbert Schulz wrote:
[...]
> Same is true here using Safari under OS X. No problem before and text
> movement now.
[...]

I have tried another fix. Let's see whether this helps...

Gerd


Herbert Schulz

unread,
Dec 17, 2012, 6:41:36 PM12/17/12
to
In article <42556223-dff5-4219...@googlegroups.com>,
Howdy,

It's back to proper behavior now; no text movement when hovering over
the button using Safari under OS X.

Good Luck,
Herb Schulz

Marc van Dongen

unread,
Dec 18, 2012, 3:29:10 AM12/18/12
to
On Monday, December 17, 2012 11:16:51 PM UTC, Gerd Neugebauer wrote:

> I have tried another fix. Let's see whether this helps...

Hi Gerd,


I have a __minor__ comment that is also related to text movement. The reason for the movement is best explained using the following example.

At the top of the main page are two hyperlinks, which are side by side:
"CTAN" and "Comprehensive TEX Archive Network". When I rest the mouse pointer on the CTAN link, the link is ``highlighted'' by displaying it in bold. As a result the link gets wider and this moves the other hyperlink a few millimetres to the right. (BTW, I'm using chrome on Ubuntu 12.10.)

As I wrote, it's a __minor__ thing but it does give the page an ``unstable'' look and feel. I suspect this can be fixed by positioning the second link at an absolute position instead of position relative to the first one.

Regards,


Marc van Dongen

Lars Madsen

unread,
Dec 18, 2012, 4:33:35 AM12/18/12
to
the search and reset buttons no longer move in my FF (17.0.1 Ubuntu)

try the same trick on the four buttons on the top row

/daleif

Gerd Neugebauer

unread,
Dec 19, 2012, 4:35:15 PM12/19/12
to
On Tuesday, December 18, 2012 9:29:10 AM UTC+1, Marc van Dongen wrote:

> Hi Gerd,

Hi,

> I have a __minor__ comment that is also related to text movement. The reason for the movement is best explained using the following example.

> At the top of the main page are two hyperlinks, which are side by side:
> "CTAN" and "Comprehensive TEX Archive Network". When I rest the mouse pointer on the CTAN link, the link is ``highlighted'' by displaying it in bold. As a result the link gets wider and this moves the other hyperlink a few millimetres to the right. (BTW, I'm using chrome on Ubuntu 12.10.)

I have seen this before. The current breadcrumb element is switched to bold when mouse is over. Thus the width changes and the text is shifted rightwards.

Maybe I will just drop the boldening. I'll think about it...

> Regards,
> Marc van Dongen

Ciao
Gerd

Jim Diamond

unread,
Dec 19, 2012, 6:42:13 PM12/19/12
to
Gerd,

works for me.

Jim

Herbert Voss

unread,
Dec 20, 2012, 6:10:03 AM12/20/12
to
Why? It doesn't hurt and others like it ... ;-)

Herbert
0 new messages