Take \tikzpicture out of karnaugh-map environment (fixes #21)

[myzhang1029]

I stumbled upon #21 myself and found this answer that claims that tikzexternalize scans for end{tikzpicture}.

This patch allows the user to place their own tikzpicture environment around the karnaugh-map-inner environment, which makes the package compatible with tikz externalization.

If the code looks reasonable, then I am also happy to add the documentation.

In this test, the results with or without externalizing (by toggling \def\testingexternalize are visually identical.

\documentclass{article}
\usepackage{karnaugh-map}
\usetikzlibrary{external}
\def\testingexternalize{0}

\if\testingexternalize1
    \tikzexternalize[prefix=kmmwe-]
\fi

\begin{document}
\if\testingexternalize1
    \begin{tikzpicture}
    \begin{karnaugh-map-inner}[4][4][1][$D$][$C$][$B$][$A$]
        \minterms{0,2,3,5,7,8,9,10,11,13,15}
        \implicant{5}{15}
        \implicantcorner{}
        \implicantedge{3}{2}{11}{10}
    \end{karnaugh-map-inner}
    \end{tikzpicture}
\else
    \begin{karnaugh-map}[4][4][1][$D$][$C$][$B$][$A$]
        \minterms{0,2,3,5,7,8,9,10,11,13,15}
        \implicant{5}{15}
        \implicantcorner{}
        \implicantedge{3}{2}{11}{10}
    \end{karnaugh-map}
\fi
\end{document}

[2pi]

Thank you for the PR! I've looked briefly at your patch, and I'm not entirely happy with introducing yet another environment(karnaugh-map-inner).

Trying to follow the design-pattern of the package, this would probably be most suitable if it were introduced as an option; see 1.3 Options in the documentation. For example as omittikzpicture or something better. It would, if I'm not mistaken, also make it easier to switch back and fourth.

Any thoughts?

[myzhang1029]

Thanks! Yes, I definitely agree that an entire new environment is a bit too messy. Changing this to an option should be doable. Maiyun Zhang (he/him)

…

On 7 Mar 2025, at 10:49, 2pi ***@***.***> wrote: 2pi left a comment (2pi/karnaugh-map#24) Thank you for the PR! I've looked briefly at your patch, and I'm not entirely happy with introducing yet another environment(karnaugh-map-inner). Trying to follow the design-pattern of the package, this would probably be most suitable if it were introduced as an option; see 1.3 Options in the documentation. For example as omittikzpicture or something better. It would, if I'm not mistaken, also make it easier to switch back and fourth. Any thoughts? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread. <https://mirrors.ctan.org/graphics/pgf/contrib/karnaugh-map/karnaugh-map.pdf#page=8> <#24 (comment)> <https://github.com/notifications/unsubscribe-auth/AFSX55FD5S4O2WACRE3KYRL2THS3ZAVCNFSM6AAAAABTD5JTQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBXGE3TMNZSHE> 2pi left a comment (2pi/karnaugh-map#24) <#24 (comment)> Thank you for the PR! I've looked briefly at your patch, and I'm not entirely happy with introducing yet another environment(karnaugh-map-inner). Trying to follow the design-pattern of the package, this would probably be most suitable if it were introduced as an option; see 1.3 Options <https://mirrors.ctan.org/graphics/pgf/contrib/karnaugh-map/karnaugh-map.pdf#page=8> in the documentation. For example as omittikzpicture or something better. It would, if I'm not mistaken, also make it easier to switch back and fourth. Any thoughts? — Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFSX55FD5S4O2WACRE3KYRL2THS3ZAVCNFSM6AAAAABTD5JTQWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBXGE3TMNZSHE>. You are receiving this because you authored the thread.

[2pi]

Before continuing, two things. How would you like to be attributed? Would this be okay(hyperlink only when appropriate, see earlier examples)?

Maiyun Zhang

Regarding licensing. Similarly to #7 (comment) I just want to check that you are aware and okay with the licensing(CC BY-SA).

[myzhang1029]

Thank you. I am fine with the attribution and license.

I have fixed the options and added some draft for the documentation. Does this look good? This option is not very visually visible, so I included sort of a not-so-useful example of a rotated karnaugh map. Please advise if you have better ideas.

[myzhang1029]

Also, in the original code, I believe there was extra space after the \end{tikzpicture} (should have been a %?). Now that we made the \end{tikzpicture} optional. For backward compatibility, I kept this extra space if omittikzpicture is false. However, this spacing is missing when omittikzpicture is specified.

Do you think this is an issue?

Please check this comparison:
karnaugh-221-label-omit-tikzpicture.pdf
karnaugh-221-label.pdf

[2pi]

Also, in the original code, I believe there was extra space after the \end{tikzpicture} (should have been a %?). Now that we made the \end{tikzpicture} optional. For backward compatibility, I kept this extra space if omittikzpicture is false. However, this spacing is missing when omittikzpicture is specified.

Do you think this is an issue?

Please check this comparison: karnaugh-221-label-omit-tikzpicture.pdf karnaugh-221-label.pdf

I agree, better to keep it like this for backwards compatibility. Might be something to look at for a future major version. May I ask how you made the examples?

[2pi]

Thank you. I am fine with the attribution and license.

Great!

I have fixed the options and added some draft for the documentation. Does this look good? This option is not very visually visible, so I included sort of a not-so-useful example of a rotated karnaugh map. Please advise if you have better ideas.

I'm thinking that an simple example would be better. Like a plain karnaugh-map environment without anything inside. Probably even just showing the code instead of the rendering for this one as this option is technical and not visual.

[2pi]

Regarding testing, I think it would be best to do something similar to karnaugh-option-implicantcolors-default.tex karnaugh-option-implicantcolors.tex while alternating the usage of the option. Both files with the exact same rendering(adding extra spacing as needed, I'm referring to what the above mentioned issue) but the first one with mix of using the option and not(not using the option, using the option, not using the option). While the second one uses the global option but the rest remains the same. What do you think?

[myzhang1029]

I agree, better to keep it like this for backwards compatibility. Might be something to look at for a future major version. May I ask how you made the examples?

They were produced with the lua-visual-debug package.

[myzhang1029]

8ba81d6 might be a little intrusive: it is to allow local environment options to override global ones (i.e. if we had \usepackage[omittikzpicture, implicantcorners]{karnaugh-map}, we can now specify (omittikzpicture=false, implicantcorners=false) to disable them for one specific environment.

Apparently it wasn't allowed in the previous versions. Please advise if I am doing this incorrectly.

[2pi]

8ba81d6 might be a little intrusive: it is to allow local environment options to override global ones (i.e. if we had \usepackage[omittikzpicture, implicantcorners]{karnaugh-map}, we can now specify (omittikzpicture=false, implicantcorners=false) to disable them for one specific environment.

Apparently it wasn't allowed in the previous versions. Please advise if I am doing this incorrectly.

Not sure... could be useful but also makes it a bit more complex. Regardless, better if we discuss this in a separate pull-request.

[2pi]

I've done a bit of changes to everything but the tests in pr24 what are your opinions on this?

[myzhang1029]

Not sure... could be useful but also makes it a bit more complex. Regardless, better if we discuss this in a separate pull-request.

I added this to implement this test:

While the second one uses the global option but the rest remains the same.

Without it, a global [omittikzpicture] would permanently enable this option for the entire document. We would have to fiddle with \@karnaughmap@options@omittikzpicture if we wanna implement the said test. What do you think? I am fine with not including this part too.

I hope this explanation makes sense though. My point is, it would be impossible to test a "mix of using the option and not" if the global option cannot be locally overridden.

[myzhang1029]

Your version in pr24 seems to better match the original structure of the environment. Looks good.

[2pi]

Sorry for the delay! Since there are a lot of back and forth in the commits for this PR. Would you mind squashing together something more sensible without the tests of pr24? Feel free to include my last commit in the branch too.

Then I will add some reasonable tests to so that we don't have to go back and fourth and delay it even more. Does it sounds good to you?