May 2019 - TeX-NL - NTG Mailing Lists

[pdflatex / lualatex] Foutmelding in pdflatex, geen foutmelding in lualatex, maar de PDF is incompleet
by Wilfred van Rooijen 09 Oct '20

09 Oct '20

Waarde allemaal, Deze vraag komt voort uit mijn eerdere bericht omtrent pdflatex en lualatex. Ik probeerde als test een van mijn Engelse teksten (die ik normaal gesproken met LuaLaTeX compileer) te compileren met pdfLaTeX, en tot mijn verbazing gaf pdfLaTeX een foutmelding, waar LuaLaTeX geen foutmelding gaf. Hieronder een minimal working example: \documentclass[11pt, twoside]{book} \usepackage{amsmath} \usepackage{bm} \begin{document} %------------------------------------------------------------------------------- % Indien gecompileerd met pdflatex: % % ! Bad mathchar (460267). % \bm@command ->\mathaccent 460267 % % l.15 $\bm{\hat B} % = \bm{\hat w} \times \bm{\hat f}$ % % Indien gecompileerd met lualatex: geen foutmelding, maar de boldface B komt % niet in de PDF %------------------------------------------------------------------------------- $\bm{\hat B} = \bm{\hat w} \times \bm{\hat f}$ \end{document} Zoals in het commentaar: als ik dit MWE compileer met pdfLaTeX krijg ik een foutmelding over de \bm{\hat B}. Als ik met LuaLaTeX compileer dan krijg ik geen foutmelding, maar de boldface B komt niet voor in het document. In de logfile van LuaLaTeX is een aanwijzing voor het probleem: Missing character: There is no 񰗫 (U+705EB) in font cmr10! De oplossing is : \bm{\hat{B}} Mijn vraag is: - waarom geeft pdfLaTeX een andere foutmelding dan LuaLaTeX in dit geval? - is er een manier om LuaLaTeX dusdanig in te stellen dat er een foutmelding komt in een gaval als dit? - waarom komen de lower case letters wel ongeschonden door de compilatie maar de upper case B niet? Groeten,Wilfred

6 13

Aankondiging oud-leden register NTG
by NTG Secretaris 24 May '19

24 May '19

Beste TeX-ers, Vorig jaar heeft de NTG een privacybeleid opgesteld aan de hand van de nieuwe EU-regels voor gegevensbescherming. Een belangrijke verandering in de NTG ledenadministratie is dat opzeggende leden voortaan per beëindigingsdatum zonder tegenbericht volledig uit de leden database worden verwijderd, omdat we vanaf dat moment geen geldige (legale) reden meer hebben om diens persoonsgegevens te bewaren. Die actie moest rechtshalve retro-actief ook worden toegepast op reeds bestaande oud-leden in de ledenadministratie. Piet van Oostrum stelde tijdens de vorige algemene ledenvergadering van de NTG voor dat we vertrekkende leden voortaan vragen of ze bij naam bekend willen blijven in een hiervoor aan te maken register van oud-leden. Dat werd algemeen gezien als een goed idee, en onze ledenadministratie en het NTG privacybeleid zijn daarop ondertussen aangepast. Ons aangepaste privacybeleid kan worden nagelezen op de website van de NTG: https://www.ntg.nl/privacy-nl.html Maar: dit nieuwe (opt-in) oud-leden register neemt niet weg dat alle gegevens van leden die hun lidmaatschap hadden opgezegd vóór deze beleidsaanpassing (dat is: sinds Juni 2018) alreeds waren verwijderd uit de leden database. Deze aankondiging van het oud-leden register dient daarom tevens om oud-leden van de NTG die alsnog willen worden opgenomen in het oud-leden register erop te wijzen dat ze zich alsnog kunnen opgeven. Vanwege de verplichte administratie is het beter om u in dat geval niet aan te melden als directe reactie op dit bericht. Eventuele aanmeldingen voor het oud-leden register graag doorgegeven via e-mail aan: penningmeester(a)ntg.nl of per post naar ons postadres: Nederlandstalige TeX Gebruikersgroep Baarsjesweg 268-I 1058 AD Amsterdam Met vriendelijke groet, Taco Hoekwater Secretaris NTG

1 0

Plaatjes van BachoTeX 2019
by Frans Goddijn 06 May '19

06 May '19

http://nonfoods.com/bachotex2019/index.html zoals is te zien was het weer een fijne TeX week!

1 0

[MAPS] De "snelheid" van LuaLaTeX
by Wilfred van Rooijen 02 May '19

02 May '19

Waarde allemaal, onlangs viel de MAPS in mijn brievenbus. Bedankt voor alle moeijte om het blad samen te stellen en op te sturen. Deze keer bevat de MAPS een artikel van Hans Hagen, "Is TeX really slow?", een leuk artikel omtrent de "snelheid" van TeX. Dit artikel gaf mij de prikkel om deze mail te schrijven. Wat wil namelijk het geval? Ik gebruik sinds een aantal jaar voornamelijk LuaLaTeX. Momenteel gebruik ik de versie van TeXLive 2018 en ik verwacht dat de TeXLive 2019 distributie binnenkort beschikbaar zal komen. Mijn ervaring met LuaLaTeX is dat het werkelijk niet vooruit te branden is. Echter.... dit gaat om teksten in het Japans, met heel veel vergelijkingen (bijvoorbeeld, uitwerkingen van huiswerkopgaven voor verschillende vakken in de "harde wetenschappen"). Het komt regelmatig voor dat de compilatie van 1 pagina meer dan een seconde kost. Het is lastig te achterhalen wat hiervan precies de oorzaak is, heeft het te maken met de fonts, heeft het te maken met de Japanse class file voor LuaLaTeX? Ik heb nooijt te moeijte genomen om het uit te zoeken, hoewel ik de indruk heb dat LuaLaTeX voor Engelse teksten ook trager is dan pdfLaTeX. Voor het zetten van Japanse teksten is er maar een "engine" die het echt goed kan: platex / uplatex (waarbij uplatex de UTF-8 versie van platex is). De uplatex engine is nog geheel traditioneel, dat will zeggen: tex -> dvi -> dvips -> ps2pdf is de optimale route. Maar dat is dus een hoop gelazer als je dingen als PGF/TikZ wil gebruiken, of als je figuren in JPG, PDF of PNG wil gebruiken. Ook dvipdfmx gaat niet zo goed samen met Japanse teksten (hoewel dvipdfmx verschilt van dvipdfm in de "verbeterde support voor CJK"). Voor uplatex zijn er eigenlijk maar 2 class files: jsarticle.cls en jsbook.cls. Dingen als memoir kun je vergeten, dat gaat echt niet samen met Japans. Sinds kort (een paar jaar) zijn de twee class files ook voor LuaLaTeX beschikbaar (ltjsarticle.cls en ltjsbook.cls). Dat werkt als een tierelier maar het is, zoals opgemerkt, vrij traag. Tot zover mijn gebruikerservaring :-)) Wilfred

3 2