4

When implementing LaTeX support for company documents, a decision must be made prior to the initial release: is the support implemented as class or as style? While there is a heap of information about writing those, I am unsure about the constraints for such a decision itself. Maybe somebody could elaborate the questions which should be asked to get a good answer.

If writing a style, I see compatibility issues since the user will use the style from some unpredictable document class and it will be difficult/impossible for me to assert that the style works from that used class.

If writing a class, I will probably delegate most of the work to a KOMA script class while my class just tweaks a few parameters (paper geometry, visual claims, fonts etc). And I will bother the user with not being able to use a fancy document class they became fond of.

Is there any good rule of thumb?

  • 1
  • 3
    If you implement a company style I assume there is a comprehensive and explicit corporate policy about the expected output. I think in that case it makes sense to implement a class and not a .sty since you want to take over the styling of the document. The fact that your users may like other document classes is largely irrelevant since they chose these document classes for their looks (or the ability to customise the looks) - and not for other functionalities (at least that is the idea). Since you take over the looks, there is no point in them insisting on their favourite class. – moewe Mar 7 '18 at 8:44
  • 3
    Now, if the company policy is more like: "Use a 12pt sans serif font, write the name of the company in ALL CAPS, put our logo on the top right, the name of the CEO in the footer and leave a 2cm margin on the right" (explicit in some cases, leaves lots of room in others), the situation might be more difficult and the pros and cons you listed may be more evenly matched. But frankly I still think you should go for a .cls. A .sty that can not be guaranteed to work is just about useless - you will either end up annoying users that things don't work as advertised... – moewe Mar 7 '18 at 8:48
  • 2
    ... even though you allowed them to keep their favourite document class and classicthesis add-on package, or you will end up fixing your template for all those eventualities ending up in a mess of class/style-dependent fixes. Again, assuming the users should not interfere with the styling of the document there are very little commands of their fancy document class that they should want to insist on using in your document (though KOMA and memoir offer some really nifty features that can not be considered to be only about styling - so things are not as easy as I say). – moewe Mar 7 '18 at 8:56
  • 2
    @moewe I think that you should consider turning your comments into an answer (don't forget to mention memoir ;-). The questioner ably put the case against using a package with an arbitrary class versus a specifically designed class, while you have expanded on the advantages of a company-specific class. – Peter Wilson Mar 7 '18 at 18:15
5

Since I spammed the comment section I might as well compile the comments here into an answer.

As David Carlisle and Peter Wilson commented, you have already done a very good job at outlining the two possible choice and their pros and cons. The only difference between the two is really that with a class you can stop a user from using an incompatible (or their favourite - it depends on the view) document class.

Specifically for your company layout the best choice may well depend on how comprehensive, detailed and explicit your corporate identity policy is.

If you have a fairly comprehensive policy, I would definitely go for a class. Document classes are mainly chosen for their looks and the ability to customise the looks. If your company imposes a specific look, there is no point in your users wanting to deviate from that by using their favourite document class - you take over the full formatting anyway.

If, on the other hand, your company policy is less overreaching, goes more along the lines of

Use a 12pt sans serif font, write the name of the company in ALL CAPS, put our logo on the top right, the name of the CEO in the footer and leave a 2cm margin on the right

leaves a lot of wiggle room in some places and has nothing to say about other areas, the two choices might be more evenly matched. I would still go for a class in that case, though. A .sty that can not be guaranteed to work is just about useless - you will either end up annoying users that things don't work as advertised even though you allowed them to keep their favourite document class and classicthesis add-on package, or you will end up fixing your template for all those eventualities leaving you with a mess of class/style-dependent fixes. Of course you could write a .sty that works together with the big three class families (standard classes, KOMA and memoir), but that is at worst about three times as time consuming (take section headings for example, I believe each of the class families has their own preferred go-to solution, you'd end up writing three bits of code to do the same thing).

This discussion somewhat naively assumes that document classes are only chosen for their looks and the abilities to customise the looks. This is probably not entirely true since some document classes (the KOMA classes and memoir come to mind) offer other nifty features as well.

If you write a document class or style maintenance is an important issue. You (or someone else) should be prepared to accept bug reports and feature request and make sure that the code conforms to best practices even as time goes by. Writing the thing once and then throwing it out there without support is asking for trouble.

You may also want to read https://github.com/johannesbottcher/templateConfusion. And if you read German maybe also https://komascript.de/latexvorlage.

  • +1 I also like the link to the German resource. Didn't know if before. – Dr. Manuel Kuehner Mar 8 '18 at 8:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.