@JasperHabicht no, between auto translate and reading the code I can manage thanks:-) Looks interesting package,I hadn't noticed it before until @Skillmon used it for an answer
@DavidCarlisle It looks indeed interesting given the fact that you obviously set an offset of lines after which the figure should be placed or that it has this column function ... nice catch!
@JasperHabicht if you understand Chinese better than Google auto-translations you could try to contact the package author and provide a translated manual...
@Skillmon I already checked their GitHub repo. Seems that they use a dtx file, so the doc is essentially part of the package. Not sure how you would be able to localise? Make a copy, remove the code and keep the doc part?
@JasperHabicht you could just write a .tex file that has the same preamble as the documentation part of the .dtx and provide that one, no need to write a .dtx here. If you need/want help with it contact me (for the TeX parts, no idea of Chinese)
@JasperHabicht then add typesetfiles = {"*.dtx", "<your-translation-file>.tex"} to build.lua and l3build doc should typeset both, their original documentation and your translation.
@JasperHabicht the line offset is (if you didn't know) very typical for packages of that sort, even the plainTeX insbox has it (and that package is really small and doesn't try to be too smart, a reason why it often works if wrapfig fails, and until now was my goto-substitution if people asked me for wrapfig-fixes)
@JasperHabicht me neither, used it much in one document, that's about it. But I get questions regarding it semi-frequently (currently helping my little sister out, and she used it often enough).
Found a case in which wrapfig does a better job than wrapstuff (with a small hack to end its effects before it'd have done it itself inside of a list -- yup, I always have to hack my way through wrapfig; but wrapstuff doesn't apply the correct parshape after the first paragraph, not yet sure why, mayhaps another bugreport is on the way...)
@JasperHabicht An English version would be awesome! I can't help with translating, but if there are problems with the setup or anything, I'd be happy to try to help.
@samcarter_xmas_is_coming Translating only the manual part (without the implementation) is totally doable. I wonder whether it makes sense to translate the implementation part as well. This might change sooner or later, while the user macros might stay more or less stable.
@JasperHabicht I think for most people, just the manual part would be sufficient.
@JasperHabicht I think I've seen similar cases for some French packages. The full doc is available in French and a short version is translated into English.
@JasperHabicht If just doing the user-doc I would make a separate tex as @Skillmon suggested. But if you want to do the code comments as well I would keep them in the same file and not duplicate the code but have Chinese then English text above each code block
@samcarter_xmas_is_coming Then I‘ll just fork on GitHub and add the translation to the repo. If the package author is fine with it, it could be uploaded to CTAN later.
@DavidCarlisle Yes. The implementation part only contains a few annotations. It might be clear to people who want to read the full code anyways … I‘ll think about it and consult with the package author.
@PauloCereda Do you know by chance whether there is an intended way of naming such additional translations (I mean the file name)? And about how to licence them?
@JasperHabicht I think if you use some language abbreviation, e.g. wrapstuff-en.pdf then texdoc can pick up the preferred version based on the users language settings ...
@samcarter_xmas_is_coming Translation ready for review by package owner ... probably not the most eloquent English ... a bit challenging to translate from a non-native language to another one =)
I just installed the MikTex updates (2022-11-25) and now even the simplest document will not compile:
\documentclass{article}
\usepackage{unicode-math}
\begin{document}
$a_b$
\end{document}
results in the following error:
! \textfont-1 is undefined (character 119887).
l.6 $a_b$
Somewhere...
@mickep I decided to do a full build so I won't have a usable system for a while. but this seems bad, why isn't the default behaviour to be compatible?
@DavidCarlisle could it be that the one who made the new fix is not a family user? I don't know. I am about amused that it seems to have ended up in miktex without(?) testing.
I have general question on tikz. Does it make difference in quality if I do the following: I have say 10 tikzpictures to make. I could make each one as STANDALONE style tex file and compile that to one pdf file. So at end, I'll have 10 pdf images files. In main document use \includegraphics to include each one as an image. VS. put all the tikzpicutes code in the main document (article style) and compile that all at once. In terms of quality, will it make difference which method to use?
@Nasser only if your standalone tikzpictures accidentally use a different font or fontsize than the document in which they should be included. If that's not the case the quality won't differ.
@DavidCarlisle it works (but not for the nicematrix question, that is something different I think). The main question is if miktex should revert to an older luatex or if it can take the next revision?
@JasperHabicht regarding your documentation translation: I think to really understand the column option you'll have to also translate the example text (or use \blindtext or something in English).
I just installed the MikTex updates (2022-11-25) and now even the simplest document will not compile:
\documentclass{article}
\usepackage{unicode-math}
\begin{document}
$a_b$
\end{document}
results in the following error:
! \textfont-1 is undefined (character 119887).
l.6 $a_b$
Somewhere...
