Giter Club home page Giter Club logo

Comments (5)

mgmillani avatar mgmillani commented on July 23, 2024

I think all .def should be kept in separate files, since they are often mutually exclusive. The .cls should be in separate files, since they correspond to different documents and shouldn't have much in common.
Finally, there are the abnt files, which I never touched so I have no idea if they should be merged or not.

from infufrgs.

kassick avatar kassick commented on July 23, 2024

OK, let's sum up what are the files we have:

  • iiufrgs.cls
  • iiletter.cls
  • sa.cls
  • ii
  • iidefs.sty
  • abntex2.cls
  • abntex2.{bst, bib}
  • abntex2{cite,abbrev}.sty
  • brazilian.babel
  • {cic, ecp, ppgc, pgmicro, dipl, diss, pep, prop-tese, tese, espec, rp,
    unibral, formais}.def
  • varilogo.eps

Some of these files are no longer needed:

  • iileter.cls -- WHO SENDS LETTERS NOWADAYS!?
  • sa.cls -- Do we still need the class for Semana Acadêmica? What are the
    requisites for the SA paper? Is threre one still?
  • varilogo.eps -- used in the iiletter.cls

Files that I THINK we do not need at all

  • abntex2.cls -- we need the other files, the cls per se, no.
  • formais.def -- Should likely check with prople from DEPINT if they ever
    use it
  • rp.def -- the same as Semana Acadêmida

Files I think we COULD move around easily:

  • iidefs.sty just holds defs for the name of the institution, which we do
    not usually change. Whoever MUST change them should not be too whiny about
    editting the iiufrgs.cls

Files that I think we could move, but not sure if moving them into the
.cls is the best option:

  • {cic,ecp}.def , {ppgc, pgmicro}.def, {dipl, diss, pep, prop-tese, espec,
    unibral}.def -- all these are just simple files to define what goes into
    the front page. We could move them all into \if\else\fi inside the .cls.
    Doing so, though, would create a long \if block.

The reason we have so many files is 'cause, at the time, Marcelo split the
definitions into two different files and I liked the strategy and did the
same for the others.

IMHO having a big .cls full of \if\else\fi is bad , and having the user who
ain't necessarily some tex guru having to copy all these files to their
project is also bad.

So, here I'm not sure.
What would be better -- maintainance simplicity (file-isolated commits,
easier to notice changes, simple files to edit, in case we need to change
the name of something...) or more simplicity of use (having the user copy a
smaller amount of files) ?

Files we could, but I don't think we should move around:

  • nominata.def -- this changes rather frequently. I think we should keep it
    as a separated file.

Files I don't know is we can move around:

  • brazilian.babel -- I have no idea if we can just add something inside the
    .cls telling babel translations to pt_BR

Files I think we could get rid of, but doing so would require major
changes

  • abnt*.{def,bib,bst,sty} -- I don't personally like the way abntex manages
    citations -- their @inproceedings format is not compatible with the .bib
    given by ACM, iEEExplore and EVERYONE ON THE BLOODY INTERNET. It's a major
    hassle for everyone going through the final stages in their thesis --
    having to split and rename fields just so it fits with abntex.

Problem is, every time ABNT wants some more cash, they'll change some tiny
detail somewhere, sell the new, updated book to every university in the
country, and all the bib styles will have to be updated to conform. Using
abntex2 bib style makes sure that we don't need to duplicate the work they
would have already done -- and if we do some change to conform to updates
in the norm, we can submit and contribute back to the project.

All would be simples if tex supported some kind of .jar with all the files
needed, so we could just zip it and tell users "drop this in your folder,
use this documentclass and then forget about it". Best we could do is to
give users a .zip and a makefile that install things on their home texmf --
then they would not have the files laying around.

Kassick.

PS. This is a TeX class for a Brazilian university. For (mostly) brazilian
students. Maintainers are (for what I know) all brazilians. OK that we
worry about foreign students who'll be using the class, but why oh why are
we discussing this in english? (I'm not opposed, and I may just as well be
the one who began answering in english ... but should we keep it or are we
just being silly?)

Em ter, 3 de mai de 2016 às 10:44, Marcelo Garlet Millani <
[email protected]> escreveu:

I think all .def should be kept in separate files, since they are often
mutually exclusive. The .cls should be in separate files, since they
correspond to different documents and shouldn't have much in common.
Finally, there are the abnt files, which I never touched so I have no idea
if they should be merged or not.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#35 (comment)

from infufrgs.

mgmillani avatar mgmillani commented on July 23, 2024

PS. This is a TeX class for a Brazilian university. For (mostly) brazilian students. Maintainers are (for what I know) all brazilians. OK that we worry about foreign students who'll be using the class, but why oh why are we discussing this in english? (I'm not opposed, and I may just as well be the one who began answering in english ... but should we keep it or are we just being silly?)

Também acho que não faz muito sentido discutirmos em inglês. Acho que comecei a commitar em inglês por costume, e daí resolvi fazer o mesmo para as issues. Embora manter as discussões em inglês ajude estrangeiros, isso atrapalha brasileiros que não falam inglês (em vários cursos não é comum saber inglês).

Some of these files are no longer needed:

  • iileter.cls -- WHO SENDS LETTERS NOWADAYS!?
  • sa.cls -- Do we still need the class for Semana Acadêmica? What are the requisites for the SA paper? Is threre one still?
  • varilogo.eps -- used in the iiletter.cls

Normas para cartas ou para SEMAC estão definidas em algum lugar? E o estilo de cartas não é usado para certificados ou documentos oficiais (e.g., carta de aceitação, algum pedido que deve ser assinado)? Se a gente tivesse alguma forma de saber que ninguém usa, seria tudo bem remover.

Files I think we COULD move around easily:

  • iidefs.sty just holds defs for the name of the institution, which we do not usually change. Whoever MUST change them should not be too whiny about editting the iiufrgs.cls

Se o arquivo contém apenas definições, por que que ele não é um .def?

What would be better -- maintainance simplicity (file-isolated commits, easier to notice changes, simple files to edit, in case we need to change the name of something...) or more simplicity of use (having the user copy a smaller amount of files) ?

Como a instalação é feita com um comando make, acho que o número de arquivos é irrelevante para o usuário. É melhor manter as definições em arquivos separados (um arquivo apenas com todas as definições seria aceitável, mas não vejo vantagem), pois esses arquivos não devem ter nada mais do que definições. Nada de escolher margens, mudar estilo de alguma coisa ou qualquer outra hack específica para um caso. Os .cls podem ter esse tipo de coisa, mas os .def não.

from infufrgs.

matthiasdiener avatar matthiasdiener commented on July 23, 2024

Just adding my two centavos:

I support "merging" the files, as suggested by kassick, such that for a thesis, one only has to copy two files (Latex class + Bibtex style) to the thesis directory.

The current installation system based on a Makefile has some serious disadvantages, such as:

  • Not all Unix systems have make installed by default
  • It's a nightmare to use the style on windows
  • It's hard to update the installed version
  • Makes it easier to support and distribute local modifications via a git repository or Dropbox

So what can be done from a practical point of view:

  1. Merging the *.def and iidefs.sty into iiufrgs.sty: This should be straightforward?
  2. the bibliography style: this will be much harder; maybe we can do something based on biblatex?

from infufrgs.

mgmillani avatar mgmillani commented on July 23, 2024

I support "merging" the files, as suggested by kassick, such that for a thesis, one only has to copy two files (Latex class + Bibtex style) to the thesis directory.

Copying the files to the thesis directory is the dirty way of installing. If you want dirty, you get dirty. If it is hard to install the class in the proper way, then we should fix this first. I would suggest to mimic the texmf directory structure. So instead of putting everything in inputs/, we could have

bibtex/bst/abntex2-alf.bst
tex/latex/iiufrgs/tese.def
tex/latex/iiufrgs/iiufrgs.cls
...

Then, manually installing the classes would be just a matter of copying two or three folders to the correct location. I think MikTeX uses the same structure, so it should help windows users as well.

As for the makefile, I don't know any alternative in this case. We could provide install scripts for other systems, but I don't use windows nor mac so I can't even test them. Maybe fixing #11 could help.

Keeping the .def in separate files has the advantage that people can create their own files, and they won't be overwritten by an update. If we merge everything, the user will have to manually apply the update. An alternative would be to add a customdef=file option for custom .def files.

from infufrgs.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.