30

In my question How to create an unnumbered algorithm with a caption?, a nice solution was suggested using \ContinuedFloat, from the caption package. However, when I use it, I get:

Package caption Warning: Unsupported document class (or package) detected,
(caption)                usage of the caption package is not recommended.
See the caption package documentation for explanation.

The package documentation says:

Please note: Many document classes already have built-in options and commands for customizing captions. If these possibilities are sufficient for you, there is usually no need for you to use the caption package at all. And if you are just interested in using the command \captionof, loading of the very small 'capt-of' package is usually sufficient.

but that's not what I'm after. I'm using a document class I've created as a (thin) wrapper based on report; I don't provide any built-ins I can use instead of \ContinuedFloat, and neither does report, as far as I can tell.

  • Is the use of caption really not recommended with the report class?
  • If so, why and what should I do about it?
  • If not, how can I 'tell' the package that mine is an 'ok class' to load with?
  • @lockstep: Oh, just a class around report for Ph.D. theses at my university. I'm the package author and it's not publicly available yet. But it's just a thin wrapper, nothing fancy or deep. – einpoklum Nov 12 '11 at 16:25
  • 1
    I don't get a warning if I compile the linked example and use the report class. Maybe the problem is caused by your "thin wrapper" -- without a MWE, it's hard to say. – lockstep Nov 12 '11 at 17:10
  • 2
    Eyal, please take a look at the log file. Right under the warning from the caption package you'll find the reason for the warning -- I assume it's a definition of \@makecaption unknown to the caption package. – Axel Sommerfeldt Nov 12 '11 at 17:53
  • Eyal, maybe it helps if you post the code of your wrapper class. But anyway, there must be a redefinition of either \@makecaption, \caption, or \@caption, otherwise the caption package would not complain. – Axel Sommerfeldt Nov 13 '11 at 16:47
  • 1
    Now all you have to do is to find out where this definition of \@makecaption is coming from. It does not seem to come from your wrapper class since it does not contain a redefinition of \@makecaption. But it's definitely not the definition coming from the report document class. To find out build a MWE, see meta.tex.stackexchange.com/questions/228/… – Axel Sommerfeldt Nov 13 '11 at 18:16
22

Perhaps not an answer, but it was too long to make it a comment. The documentation of the caption package says:

If you don’t find the document class you use in this section, you usually don’t have to worry: Many document classes (e.g. the octavo class) are derived from one of the standard document classes article, report, or book, and behave the same regarding captions. The caption package automatically does a compatibility check against the document class used and will give you the clear warning

Package caption Warning: Unsupported document class (or package)
detected, (caption) usage of the caption package is not recommended.
See the caption package documentation for explanation.

if such an incompatibility was detected. If you don’t get such warning everything is fine, but if you get it the usage of the caption package is not recommended and especially not supported.

If you get such a compatibility warning but decide to use the caption package anyway, you should watch carefully what side-effects occur, usually the look and feel of your captions will change by just including the caption package without options, meaning they do not look like as intended by the author of the document class. If this is fine for you, you should first specify the option style=base via \usepackage[style=base]{caption} or \captionsetup{style=base} to set the caption package into a well-defined state. Afterwards you can start setting your own options additionally and keep your fingers crossed.

Also, according to the documentation, the supported document classes are:

  • Standard LaTeX: book, report, article
  • AMS: amsart, amsproc, amsbook
  • beamer
  • KOMA-Script: scrreprt, scrartcl, scrbook
  • NTG: artikel, rapport, boek
  • SMF: smafart, smfbook
  • thesis

So, there's no problem using caption with the standard report document class. Since you are using a derived document class, you should pay attention to the last paragraph of the quote at the beginning of this message.

  • 3
    So if I know that my derived document class is essentially the same as one of the officially approved document classes, how can I tell the caption package to hide its warning? – Tyson Williams Nov 8 '12 at 20:56
  • 1
    Perhaps this is an answer? – Daniel May 31 '13 at 6:10
  • I wonder if the caption package can't figure out on its own whether it's loaded in a 'safe' context. – einpoklum May 31 '13 at 10:34
  • Not an answer to the question – jean-loup Jun 20 '18 at 8:28
21

One of your packages tries to load captions twice. I have the same issue because I'm loading the \subfig package, this blog post give an elegant solution:

Find the offending package and load it without the caption package.

\usepackage[caption=false]{subfig}

This has worked for me. It would really help though if you gave us your header and we could try and spot what was trying to load caption, and reduce the number of packages doing that to one.

  • Unlikely... I load it manually, and if I remove my \usepackage[style=base]{caption} my \ContinuedFloat doesn't work. – einpoklum Jan 17 '12 at 19:03
  • 1
    saved me a lot of time. – ar2015 May 12 '18 at 6:04
7

Gonzalo's answer has explained why you can or can not include the caption package.

If you are sure you want to use it, and want to get rid of the warning, use

\usepackage{silence}
\WarningFilter{caption}{Unsupported document class}
2

You said

I had to get rid of subcaption (which it turns out I wasn't using anyways).

However, this is not true. subcaption loads caption anyway.

\ProvidesPackage{subcaption}[\caption@tempa v1.1-\caption@tempb Sub-captions (AR)]
\RequirePackage{caption}[2012/03/25] % needs v3.3 or newer

Indeed caption.sty and subcaption.sty are both part of the caption package.

This means that you can say

\usepackage{subcaption}

and will automatically have loaded caption also.

However, it doesn't matter if you also say

\usepackage{caption}

or

\usepackage[style=base]{caption}

Indeed, I cannot reproduce the warning you report using any combination of these lines in any order.

Nor do I get an error if I remove the line loading caption, provided I retain the line loading subcaption which itself loads caption.

Whatever the source of the conflicting definition in your files, it does not appear to be the use of subcaption in combination with caption. Indeed, it would be most peculiar were this the case, given that subcaption needs caption.

1

A solution for this problem can be found here.

You can create in your project a file support-caption.sty

\setlength\abovecaptionskip{\f@size\p@}
\setlength\belowcaptionskip{0\p@}
\long\def\@makecaption#1#2{%
  \vskip\abovecaptionskip
  \sbox\@tempboxa{#1: #2}%
  \ifdim \wd\@tempboxa >\hsize
    #1: #2\par
  \else
    \global \@minipagefalse
    \hb@xt@\hsize{\hfil\box\@tempboxa\hfil}%
  \fi
  \vskip\belowcaptionskip}

Then, put in your preambule this:

\usepackage{support-caption}
\usepackage{subcaption}
  • 3
    You only repeat that answer. Don't do this; add a link to it as a comment instead. – Martin Schröder Jul 24 '17 at 15:34
  • Share the link was the first thing I did. I'm just trying to help. Sorry for any inconvenient. :-) – Waldeyr Mendes da Silva Jul 25 '17 at 18:37

protected by Joseph Wright Jul 25 '17 at 7:37

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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