CTAN Comprehensive TeX Archive Network

Ad­di­tional In­for­ma­tion for CTAN Upload­ers

Be­fore study­ing these ad­di­tional notes, you should have read and un­der­stood the fol­low­ing ba­sic texts:

  1. CTAN's help page “How can I up­load a pack­age?”,
  2. the TeX Live in­struc­tions, and
  3. the cor­re­spond­ing ar­ti­cle of the UK TeX FAQ.

The fol­low­ing pa­per tries to give some back­ground in­for­ma­tion about CTAN it­self, fol­lowed by a list of more as­pects we ask you keep in mind when prepar­ing your up­load, some hints about how to use the up­load form and fi­nally in­for­ma­tion about what will hap­pen to your sub­mis­sion once it has ar­rived at our place.


Some back­ground in­for­ma­tion

Struc­ture of the net­work

The Com­pre­hen­sive TeX Archive Net­work con­sists of a cen­tral server at Cologne in Ger­many and a great num­ber of mir­rors all over the world.

All these servers should in prin­ci­ple present the same con­tent – an ideal that is of course reg­u­larly dis­turbed with ev­ery in­stal­la­tion of a new up­load; but ev­ery mir­ror should syn­chro­nize with the cen­tral server once ev­ery day, so that the ap­prox­i­ma­tion to that ideal is in­deed quite close.

Struc­ture of the archive

The greater part of the archive is taken up by what we re­fer to as the un­packed tree”. It is meant for be­ing vis­ited by means of a browser. To make this not too painful an ex­pe­ri­ence, the in­di­vid­ual sub­trees of this part of the archive are re­quired to be as “flat” as pos­si­ble, i.e. they should con­tain as few di­rec­tory lev­els as pos­si­ble, re­gard­less of the po­si­tion of the in­di­vid­ual files in a “real” TeX sys­tem.
We do how­ever not im­pose any def­i­nite up­per limit on the num­ber of di­rec­tory lev­els in a pack­age's lay­out as there seems to be no up­per bound to pack­ages' com­plex­ity. Please con­tact the CTAN team for ad­vice if your pack­age is very com­plex and you are in doubt about how best to ar­range your ma­te­rial.

In ad­di­tion to this there is what we call the in­stall tree”, which is a col­lec­tion of .tds.zip files.

Please note that ev­ery pack­age on the archive must be present in the “un­packed” part. The .tds.zip files are op­tional ad­di­tions that may be use­ful for big and com­plex pack­ages, but are in no way re­quired by the CTAN team, whereas we do not ac­cept up­loads that con­tain noth­ing but a .tds.zip file.

URLs

There are many ways of re­fer­ring to CTAN pack­ages on the in­ter­net, but our pre­ferred, “canon­i­cal” ones are of the fol­low­ing form:

  1. https://ctan.org/pkg/… (where the “…” equal the “pack­age id”) if you are in­ter­ested in in­for­ma­tion about the pack­age, and
  2. http://mir­ror.ctan.org/… (where the “…” equal the “path” to the pack­age's files on the archive) if you are in­ter­ested in the pack­age it­self.

In par­tic­u­lar, URLs con­tain­ing the string “tex-archive ” are gen­er­ally “sus­pi­cious”, be­cause they usu­ally re­fer to the cen­tral server, and we try des­per­ately to redi­rect down­load de­mands from the cen­tral server to the mir­rors. More­over, the in­di­vid­ual servers and their ad­dresses may change over the times, whereas these “canon­i­cal URLs” are in­tended to be per­ma­nent.

The CTAN team

At the mo­ment, the fol­low­ing per­sons (in al­pha­bet­i­cal or­der) take care of CTAN:

  • Erik Braun (up­load man­age­ment),
  • Ina Dau (up­load man­age­ment),
  • Man­fred Lotz (up­load man­age­ment),
  • Gerd Neuge­bauer (web de­vel­oper),
  • Pe­tra Rübe-Pugliese (up­load man­age­ment),
  • Rainer Schöpf (sys­tem ad­min­is­tra­tion and su­per­vi­sion of mir­rors),
  • Joachim Schrod (sys­tem ad­min­is­tra­tion).

All these peo­ple are act­ing as vol­un­teers in their spare time; so please do not get im­pa­tient if your re­quest does not re­ceive an im­me­di­ate an­swer: they may be held up by “real life” prob­lems or a sud­den in­rush of other up­loads.

Email ad­dress

All CTAN re­lated cor­re­spon­dence should be di­rected in English to ctan (at) ctan (dot) org , the com­mon email ad­dress of all “CTAN peo­ple” con­cerned with up­load man­age­ment or sys­tem ad­min­is­tra­tion.

Please take care that the emails you send to this ad­dress are plain text only, with­out any HTML part, be­cause HTML mails are held in CTAN's spam fil­ter and it may take some time un­til a post­mas­ter comes along to set them free. (If you are us­ing gmail, you can se­lect “plain text mode” click­ing on the “more op­tions” tri­an­gle in the bot­tom right cor­ner of the win­dow where you are com­pos­ing your mes­sage. Also, your “gmails” will al­ways be sent in plain text mode when you ac­cess google's web­mail via the “ba­sic HTML view” in­ter­face.)

Never try to up­load (or re-up­load) by email, al­ways use the up­load form, for the fol­low­ing rea­sons: (a) The many re­cip­i­ents of these mails are gen­er­ally not happy to see their mail­boxes bloated with soft­ware con­tri­bu­tions, (b) email at­tach­ments end up on the wrong com­puter and we have to per­form an ad­di­tional file trans­fer, and (c) up­loads via the up­load form very con­ve­niently gen­er­ate a num­ber of au­to­mated mails that help us with the doc­u­men­ta­tion of our ac­tiv­i­ties and can be eas­ily con­verted to ac­knowl­edge­ment mails and an­nounce­ments.

More gen­er­ally, no big at­tach­ments should be sent to this email ad­dress, mainly be­cause of ar­gu­ment (a) above.


More re­quire­ments on your up­load …

  1. Con­di­tions on file­names:
    1. File­names should not con­tain any spaces, tabs, new­lines, or other whites­pace char­ac­ters be­cause file­names with whites­paces in them can make work on a UNIX com­mand line ex­tremely awk­ward.
    2. File­names should not con­tain any non-ascii char­ac­ters, for porta­bil­ity rea­sons.
    3. File­names should not con­tain any char­ac­ters that have a spe­cial mean­ing for UNIX shells (or other sys­tems), such as ex­cla­ma­tion and ques­tion marks, as­ter­isks, am­per­sands, slashes, back­slashes, pipe sym­bols, dol­lar signs, any sort of brack­ets, and paren­the­ses.
    4. File­names should not start with a dot (“in­vis­i­ble files” in UNIX-like op­er­at­ing sys­tems).
    5. Unique file­names: This topic has been dealt with in de­tail in two of the three “ba­sic texts” men­tioned above, es­pe­cially with re­gard to “run­time files”. — Let's add here (a) that unique­ness of file­names over the whole archive would in­deed be our ideal (that is of course im­pos­si­ble to achieve – think of stan­dard­ised names like “README” and “Make­file”!); but nev­er­the­less that ideal should at least be ap­proached as closely as pos­si­ble. In par­tic­u­lar, we strongly rec­om­mend unique­ness of file­names within ev­ery sin­gle pack­age. Am­bi­gu­ity is never a good thing, and it may prove harm­ful in un­ex­pected sit­u­a­tions.
      (b) Let us re­mind you that there are op­er­at­ing sys­tems un­able to dis­tin­guish be­tween my­file and MyFile . That's why we check for “iden­ti­cal file­names” af­ter con­vert­ing ev­ery­thing to “low­er­case”.
    6. You may how­ever be pleased to learn that we have not been ask­ing for MS-DOS-style 8.3 file­names for a long time ;-)
  2. Con­di­tions on pack­age ids:
    Every CTAN pack­age is uniquely iden­ti­fied by its “pack­age id”, which ap­pears, for in­stance, as the last part in URLs like https://ctan.org/pkg/ge­om­e­try (here “ge­om­e­try” is the pack­age's id.)
    1. Of course, all the con­di­tions on file­names de­scribed above also ap­ply to pack­age ids.
    2. More­over, pack­age ids have to be all low­er­case, and they must not start with a digit.
      (To ease some of the harsh­ness of this par­tic­u­lar rule, pack­age names have been in­tro­duced which can be seen at the be­gin­ning of the ti­tle line of their “CTAN home page”. For in­stance, at the top of https://ctan.org/pkg/ar­sclas­sica you see “ArsClas­sica”, at the top of https://ctan.org/pkg/mathtype you see “MathType”, at the top of https://ctan.org/pkg/one2­many you see “12many”, etc. Of course, the CTAN team pre­fer, for the sake of sim­plic­ity, to have “pack­age name = pack­age id”, but small vari­ants like CamelCase are ac­cepted for the “names”.)
    3. CTAN and TeX Live have a pref­er­ence for hy­phens in pack­age ids, rather than un­der­scores. There are at the mo­ment (Septem­ber 2018) 1151 Cat­a­logue en­tries with a hy­phen in their name vs. 17 with an un­der­score. You will there­fore have to give very good rea­sons if you want us to ac­cept the 18th pack­age with an un­der­score in its id ;-) .
    4. Pack­age ids start­ing with “l3 are re­served for of­fi­cial LaTeX Project ex­pl3 pack­ages. Pack­age au­thors are en­cour­aged to con­sider us­ing “lt3... ” for third-party ex­pl3 pack­ages.
    5. New pack­ages and bun­dles should not be named af­ter their au­thors, but af­ter the pur­pose they are serv­ing, be­cause they may later be taken over by other main­tain­ers. (We know that there are a few well es­tab­lished CTAN pack­ages that do not ful­fill this rule; but that comes un­der “pro­tec­tion of vested rights”, and we have now learned from his­tory.)
    6. In the same way, cryp­tic pack­age ids like “acs”, “mxd”, “tpx”, or “tcvn” are nowa­days strongly dis­cour­aged. Modern pack­age ids should as best as pos­si­ble con­vey to the av­er­age user an idea of what the pack­age is about.
  3. Ver­sion iden­ti­fier:
    Every sub­mis­sion of ev­ery CTAN pack­age has to con­tain a “ver­sion iden­ti­fier” that per­mits to dis­tin­guish this ver­sion of the pack­age from ear­lier or later ones. This iden­ti­fier should of course co­in­cide with the one you will later en­ter into the “Ver­sion” field of the up­load form.
    This ver­sion iden­ti­fier may con­sist of
    1. Either (only) a ver­sion num­ber, i.e. some­thing like “1.0”, or “3.0.17”, or “2.1a”,
    2. or (only) a ver­sion date, prefer­ably in YYYY-MM-DD or YYYY/MM/DD no­ta­tion, like “2018-12-06” or “2018/12/06”,
    3. or a string con­sist­ing of both the afore­men­tioned data.
    For sim­ple LaTeX pack­ages, the op­tional ar­gu­ment of the \Pro­videsPack­age or \Pro­videsClass com­mand of the .sty or .cls file should be a good place where to put this in­for­ma­tion.
    For bun­dles that con­sist of var­i­ous files with pos­si­bly dif­fer­ent ver­sion iden­ti­fiers of their own, the whole bun­dle should be marked with a “bun­dle ver­sion iden­ti­fier” re­fer­ring to the bun­dle as a whole. A good way to achieve this is “tag­ging” the bun­dle with the date of the lat­est change of any of its files. Put this “tag” into a place where it is easy to find, such as the lat­est en­try of a Changes file, a VERSION file, or an eas­ily ac­ces­si­ble place (prefer­ably: the top part) in the README file.
    Please note that in our mind the doc­u­men­ta­tion is con­sid­ered part of the “pack­age”. So even if “only” a tiny de­tail of the doc­u­men­ta­tion (and noth­ing what­ever in the “run­time files”!) has changed, the ver­sion num­ber, if it is part of the ver­sion iden­ti­fier, has to in­crease at least slightly.
  4. Low re­dun­dancy:
    Be­cause of the well known dis­ad­van­tages of re­dun­dancy – es­pe­cially the risk of in­con­sis­tency! – we try to keep it as low as pos­si­ble on the un­packed archive. In par­tic­u­lar …
    1. … we do not wish to hold iden­ti­cal copies of one and the same file (“du­pli­cate files”) in dif­fer­ent places, such as for in­stance README and doc/README .
      If you re­ally think you need copies of a file in other places, then please re­place these copies with sym­bolic links (a.k.a. sym­links or soft­links) point­ing to the “orig­i­nal” file. — Be­ware: When pack­ing your up­load file with zip , you will have to call it with the --sym­links op­tion (or some­thing equiv­a­lent, de­pend­ing on your par­tic­u­lar zip pro­gram) if you do not want the sym­link to be re­placed by a copy of the orig­i­nal file again!
      (Mind that this re­quest con­cerns only the un­packed part and that a sim­i­lar rec­om­men­da­tion does not hold for the con­tents of .tds.zip files: .tds.zip files are sup­posed to be un­packed with­out prob­lems on ar­bi­trary plat­forms, and this can­not be guar­an­teed if they con­tain sym­bolic links!)
    2. … we do not wish to hold files that can be eas­ily gen­er­ated” (“de­rived”) from other files con­tained in the sub­mis­sion. The stan­dard ex­am­ples of this are .cls , .sty , .clo , .fd or sim­i­lar LaTeX files, when they can be gen­er­ated from their .dtx source in a straight­for­ward way.
      The ex­cep­tion to this rule are the .pdf files of the doc­u­men­ta­tion: We do in­deed wish to keep these, ready for im­me­di­ate ac­cess by vis­i­tors, along­side with their sources.
      The same holds for README files in cases where these, too, can be gen­er­ated from other sources: We al­ways want the README un­packed, as a con­ve­nient start­ing point for in­spect­ing the pack­age.
  5. No aux­il­iary files:
    This con­cerns op­er­at­ing sys­tem spe­cific data (like __MACOSX di­rec­to­ries and .DS_Store files), .git , .git­ig­nore , .hgig­nore , .hg­tags , ed­i­tor backup files (.backup , .bak , .sav , .~ , …), as well as “left­overs” from TeX & friends and other pro­grams (.aux , .log , .acn , .acr , .alg , .bbl , .bcf , .blg , .brf , .cb , .cb2 , .ent , .fdb_la­texmk , .fff , .fls , .fmt , .fot , .gaux , .glog , .gtex , .ilg , .ind , .idx , .glo , .lg , .loa , .lod , .lof , .lol , .los , .lot , .lox , .nav , .out , .pre , .pyg , .snm , .soc , .toc , .vrb , .cpt , .dvi , .glg , .gls , .gls­defs , .idv , .maf , .mlf , .mlt , .mtc , .nlg , .nlo , .nls , .spl , .thm , .tmb , .tmp , .tuc , .upa , .upb , .o , .sta , .swp , .tdo , .trc , .ttt , .url , .w18 , .xdv , .xref , .4ct , .4tc , .run.xml , .pdf­sync , .sync­tex , .sync­tex.gz , and po­ten­tially oth­ers we have not yet en­coun­tered): Please leave them out of your up­load!
    Note for git users wish­ing to keep ex­ported .zip files “git rub­bish free”: This can be achieved by cre­at­ing, adding and com­mit­ting a .gi­tat­tributes file con­tain­ing lines like the fol­low­ing:
               .gitignore     export-ignore
               .gitattributes export-ignore
             
    Note for Mac OSX users: A user told us that “it is pos­si­ble to tell Mac OSX's tar com­mand line ex­e­cutable to avoid pol­lut­ing the archive with OSX spe­cific files, by set­ting the en­vi­ron­ment vari­able COPYFILE_DISABLE (to what­ever value).”
  6. No empty files or di­rec­to­ries:
    We tend to con­sider empty files and di­rec­to­ries as “rub­bish”. If you feel oth­er­wise and wish to con­serve such files for sys­tem­atic rea­sons, we rec­om­mend fill­ing them with some com­ment (in the case of “reg­u­lar files”) or a place­holder file (in the case of di­rec­to­ries) ex­plain­ing their pur­pose.
    If this is not pos­si­ble be­cause the pro­gram us­ing these files would get dis­turbed by com­ments or “dummy files”, please men­tion this in the “Ad­min­is­tra­tive notes” field of the up­load form so that we can make a note of this ex­cep­tion and do not bother you with un­nec­es­sary com­plaints.
  7. File per­mis­sions:
    1. Only files that are truly ex­e­cutable (like Shell, Perl, Python, Ruby, and other scripts) should be marked as such. An “ex­e­cutable” README or .tex file does not make any sense.
    2. Files sub­mit­ted to CTAN are ob­vi­ously meant for pub­li­ca­tion. This im­plies that they should be “world read­able”. (In fact, ex­ag­ger­ated “pri­vacy” of file per­mis­sions can lead to se­ri­ous com­pli­ca­tions in the in­stal­la­tion pro­cess.)
  8. Line ter­mi­na­tors of text files:
    This para­graph is about text files (like .txt , .tex , .sty , .cls , .dtx , .fd , .bib , .c , or any other file that can be edited with a text ed­i­tor) as op­posed to “bi­nary files” (such as .gif , .jpg , .wav , .mp3 , .ogg , .tfm , .pdf , .doc , .xls , .exe , and a mul­ti­tude of oth­ers).
    The prob­lem with such text files is that dif­fer­ent op­er­at­ing sys­tems have dif­fer­ent ways of mark­ing the line end­ings within them: Whereas Mi­crosoft sys­tems de­scribe a line end­ing in the good old type­writer fash­ion by a “car­riage re­turn” char­ac­ter fol­lowed by a “line feed” char­ac­ter, UNIX type op­er­at­ing sys­tems have al­ways omit­ted the “car­riage re­turn”, and mod­ern Mac OS X sys­tems do it the same way.
    As CTAN's servers are run­ning on UNIX-like op­er­at­ing sys­tems, the CTAN team have de­cided that all text files on the archive should have suit­able “line­feed only” line ter­mi­na­tors.
    Now, if you are a Win­dows user, you need not be alarmed, as there is an easy way to com­ply with this wish, with hardly any in­con­ve­nience for your­self: If you pack your up­load file with a “good zip pro­gram”, this will mark all text files with a spe­cial “flag” (or “tag”) that will per­mit CTAN's un­zip pro­gram to rec­og­nize these text files and per­form the nec­es­sary con­ver­sions (in this case: omit­ting the un­wanted “car­riage re­turn” char­ac­ters) au­to­mat­i­cally :-)
    Un­for­tu­nately, not all zip pro­grams are “good zip pro­grams” :-(
    In par­tic­u­lar, 7zip, the GNOME archive man­ager, the Com­press fa­cil­ity ac­ces­si­ble via the File menu in Mac OS X's Fin­der , and the fea­ture that per­mits to ex­port zip files di­rectly from git repos­i­to­ries do not seem to have the de­sired prop­erty. (Please cor­rect us if there has been re­cently some pos­i­tive de­vel­op­ment we are not aware of by writ­ing us an email!)
    How­ever, git users may want to have a look at the .gi­tat­tributes file for the con­fig­u­ra­tion of file types and line end­ings!
    Known “good zip pro­grams” are the Win­dows7ff. builtins, WinZip, Win­dows “To­tal Com­man­der”, and the zip­pers from info-zip.org.
    Mac users in need of a “good zip pro­gram” may ei­ther turn to Ye­muZip or the stan­dard zip com­mand on their com­mand line (which is in fact the info-zip tool that is also present in Linux sys­tems). The com­mand line zip­info util­ity is ex­tremely use­ful for check­ing zip archives once they have been cre­ated.
    Un­for­tu­nately, tar does not of­fer the “tag­ging” fea­ture in ques­tion.
    Fi­nally, there are two ex­cep­tions to what has been said be­fore:
    1. If your up­load con­tains any .bat or .cmd or .nsh or other typ­i­cal DOS/Win­dows files, and if you wish to pre­serve their CR+LF line end­ings, please drop us a line to that ef­fect in the “Ad­min­is­tra­tive notes (to the CTAN main­tain­ers)” field of our up­load page, and we will take care that this is done.
    2. All the .tds.zip files we of­fer on the archive are sup­posed to have noth­ing but UNIX style line ter­mi­na­tors in­side as well as the nec­es­sary .zip flags for un­pack­ing them in the best pos­si­ble way on any op­er­at­ing sys­tem. That's why we wish .tds.zip files to be sub­mit­ted in ex­actly that way. (If there should re­ally be a prob­lem that pre­vents you from com­ply­ing with this re­quire­ment, we may find a way to cor­rect this short­com­ing at our end, but we would of course much pre­fer not to have to re­sort to any such ma­nip­u­la­tions.)
  9. “Canon­i­cal” URLs in doc­u­men­ta­tion:
    Please make sure when writ­ing (or re­vis­ing) your doc­u­men­ta­tion that TeX soft­ware on CTAN archives is re­ferred to us­ing our pre­ferred “canon­i­cal” URLs de­scribed above rather that URLs point­ing to in­di­vid­ual CTAN servers.
  10. Rules about README files:
    1. Every pack­age shall be ac­com­pa­nied by a README file giv­ing a short in­tro­duc­tion to the pack­age's pur­pose as well as sig­nif­i­cant data like au­thor's name and con­tact, li­cense etc.
    2. Its name can be ei­ther README or README.txt or README.md , but no other vari­ants are per­mit­ted at the mo­ment.
    3. Its con­tents must be eas­ily read­able us­ing the UNIX more or less com­mands or an ar­bi­trary ed­i­tor.
    4. It should be writ­ten in English or at least com­prise a short ab­stract in English.
    5. The en­cod­ing should be ascii or utf-8.
    6. It has to be placed at the top level of the un­packed pack­age (but in the doc/…/ di­rec­tory of a pos­si­ble .tds.zip file).

Upload­ing to CTAN

When you feel con­vinced that you have done all you can to com­ply with the re­quire­ments de­scribed up to now, you may go on to pack­age your sub­mis­sion us­ing ei­ther zip or tar , as de­scribed on our help page. – Do not for­get the top level di­rec­tory of the up­load file (“my-pack­age/ ” in the ex­am­ples). It sim­pli­fies our in­stal­la­tion pro­cess and makes it more se­cure. – Please opt for a good zip pro­gram (in­stead of tar or any zip pro­gram) if you are not one hun­dred per­cent sure that none of your text files con­tains any “Mi­crosoft style” line ter­mi­na­tors!

If you want to sub­mit an up­date to a pack­age that is al­ready on CTAN, we rec­om­mend you to go first to its “CTAN home­page” (https://ctan.org/pkg/<pack­a­ge­name> ) and then click on the “Upload” but­ton. You will find that some of the more te­dious fields have al­ready been filled in with in­for­ma­tion from our Cat­a­logue :-)   But please do not for­get to up­date the ver­sion field!

Please pay also par­tic­u­lar at­ten­tion to what you en­ter into the “Your email” field: In fact, we ask main­tain­ers to use al­ways the same email ad­dress when con­tact­ing the CTAN team. In par­tic­u­lar, given the (im­prob­a­ble, but not com­pletely un­real) dan­ger of unau­tho­rized up­load­ers over­writ­ing “good” pack­ages, we will refuse to in­stall an up­date if it is not sub­mit­ted us­ing an email ad­dress known to the CTAN team. — BTW: When­ever you plan to change your “CTAN up­load email ad­dress”, do not for­get to drop a line to ctan (at) ctan (dot) org, still us­ing the old ad­dress, and ask­ing us to reg­is­ter the new one.


What will hap­pen next …

  • Every up­load will be un­packed and checked by an up­load man­ager.
  • Small de­fi­cien­cies will be cor­rected im­me­di­ately by that per­son. You will re­ceive feed­back about this and be asked to ap­ply the same sort of change(s) to your own file(s) be­fore your next up­load.
  • If there is a non-triv­ial prob­lem we can­not or do not want to re­solve on our own, we will ask back and the in­stal­la­tion pro­cess will be mo­men­tar­ily stalled un­til we re­ceive an an­swer to our ques­tion. In some cases even a re-up­load may be­come nec­es­sary.
  • After in­stal­la­tion of the pack­age on the archive (i.e.: on our cen­tral server) the cor­re­spond­ing .xml source file of the Cat­a­logue en­try will ei­ther have to be cre­ated “from scratch” (for new pack­ages) or be up­dated (in all other cases; mostly only the ver­sion field, some­times the copy­right line(s) or de­tails about the point­ers to the doc­u­men­ta­tion). Please use the “Ad­min­is­tra­tive notes (to the CTAN main­tain­ers)” field in the up­load form if you wish us to per­form any other changes.
  • When all of this has been done, we will send an email to the ad­dress you en­tered into the “Your email” field of the up­load form.
  • It may take a few hours un­til the Cat­a­logue page of the web­site has been re­gen­er­ated from the source file, and up to 24 hours un­til the new files have ar­rived on all the mir­rors world­wide.
  • If your up­load is a new one or if you have re­quested an an­nounce­ment, the mes­sage to CTAN-An­nounce will be posted if pos­si­ble shortly af­ter the end of that 24 hour de­lay. There may how­ever be a fur­ther de­lay due to the main­tainer's work­ing hours or other en­gage­ments at that time. If the mes­sage has not ap­peared af­ter more than 48 hours, you should write a mes­sage to ctan (at) ctan (dot) org to en­quire if any­thing has gone wrong.
  • It is al­ways help­ful if you check what you see at the URLs in­di­cated in the ac­knowl­edge­ment mail around 24 hours af­ter in­stal­la­tion and in­form us about any pos­si­ble flaws in the pre­sen­ta­tion.

Please do not re-up­load when you do not hear from us at once! There may have been a sud­den in­rush of up­loads and/or main­tain­ers may have been kept from at­tend­ing to your up­load by “real” work, fam­ily mat­ters, tech­ni­cal prob­lems, hol­i­days, ill­ness, or other causes. If you still haven't heard from us af­ter let's say three or four days, and have checked your spam folder to no avail, you may en­quire by email to ctan (at) ctan (dot) org (re­mem­ber: No HTML mail please, be­cause of the spam trap!).

Thanks for your per­se­ver­ance and good luck with your sub­mis­sion!


Some ad­di­tional in­for­ma­tion about au­thor ids and user ac­counts

Every au­thor/main­tainer of a CTAN pack­age is reg­is­tered in the database that is used for the ad­min­is­tra­tion of the archive it­self with an au­thor id that is as­signed in the fol­low­ing way:

As a gen­eral rule, the au­thor id equals the au­thor's fam­ily name, down­cased and with non-ascii char­ac­ters con­verted to ascii. For in­stance, new au­thor Ben­jamin Blümchen would re­ceive the au­thor id “bluem­chen”.

If how­ever an­other au­thor of the same fam­ily name is al­ready reg­is­tered, the newer au­thor's id will be mod­fied us­ing the first let­ter(s) of his or her given name. For in­stance, if at a later time Hilde­gard Blümchen were to join us as an au­thor, she would be reg­is­tered as “bluem­chen-h”.

Th­ese au­thor ids must not be con­fused with the names of the user ac­counts on the CTAN web­site: The names of these user ac­counts can be cho­sen rel­a­tively freely, as long as unique­ness is as­sured.

A re­la­tion be­tween a per­son's au­thor id and their CTAN web­site user ac­count can be es­tab­lished via the email ad­dress. In our web­mas­ter's own words:

Once you are logged into the CTAN site and visit the page https://ctan.org/user/set­tings (link in the up­per right cor­ner), you will find the sec­tion “CTAN Con­trib­u­tor Con­fir­ma­tion” where you can con­firm the re­la­tion be­tween the au­thor id and the cur­rent ac­count by set­ting the check-mark. In the same way you can re­move the re­la­tion by uncheck­ing.
This fea­ture is of­fered when one of the known email ad­dresses in the au­thor database matches the email ad­dress of the ac­count (which can be edited on the same page).

Last up­dated: 2018-09-17
Guest Book Sitemap Contact Contact Author