De zwarte blokjes worden door draft gegenereerd. Is bij jou de linker kolom niet langer, doordat onder twee van de mintekens (de eerste twee) een lege regel staat? Dan heb jij andere fontfiles dan wij, denk ik: $ grep -i deja main.fls|sort -u INPUT /usr/local/texlive/2011/texmf-dist/fonts/enc/dvips/dejavu/dejavumono_ot1.enc INPUT /usr/local/texlive/2011/texmf-dist/fonts/tfm/public/dejavu/DejaVuSansMono-tlf-ot1.tfm INPUT /usr/local/texlive/2011/texmf-dist/fonts/type1/public/dejavu/DejaVuSansMono.pfb INPUT /usr/local/texlive/2011/texmf-dist/tex/latex/dejavu/DejaVuSansMono.sty INPUT /usr/local/texlive/2011/texmf-dist/tex/latex/dejavu/OT1DejaVuSansMono-TLF.fd On 2012-02-24 09:34, Wilfred van Rooijen wrote:

Hoi allemaal,

Ik heb de testfile gedownload, maar wat moet er nu precies misgaan? Ik heb de \usepackage{DejaVuSansMono} weggehaald, en daarna met xelatex gecompileerd. Ik krijg twee kolommen met tekens (linkerkolom 1 x x x - x - x - x met kleine vierkantjes ernaast, en de rechterkolom 3 x x x - x - x - x). Alles lijkt in orde, alle symbolen staan netjes uitgelijnd.

?

Wilfred

------------------------------------------------------------------------ *From:* Pander *To:* tex-nl *Sent:* Friday, 24 February 2012, 1:12 *Subject:* [Tex-nl] Fontafhankelijke ongewenste extra witregel na minteken

Hoi allemaal,

Met sommige fonts ontstaat er een extra witregel bij specifiek gebruikt van een los minteken.

Wybo en ik hebben dit onderzocht en het is een hele lastige. Waarschijnlijk heeft het met woordafbreken te maken. Het is iets dat alleen bij sommige fonts optreed maar het ligt niet aan die fonts zelf maar hoe TeX hier mee omgaat.

Steve White van GNU FreeFont heeft hiervoor naar de fonts gekeken en dit bevestigd. Een workaround voor deze gevallen is een mbox of fbox maar er moet een robuuste oplossing voor gevonden worden. Het is reproduceerbaar in XeLaTeX, PDFLaTeX en LaTeX.

Hieronder is het minimale voorbeeld voor TeX dat Wybo heeft gemaakt. Wie van de TeX-experts weet dit op te lossen?

Groetjes,

Pander

\documentclass[draft,12pt]{article} \usepackage[papersize={30mm,70mm},noheadfoot,margin=5mm]{geometry} \usepackage{longtable} \usepackage{DejaVuSansMono} \parindent0pt\pagestyle{empty} \fboxsep0mm\fboxrule.01mm \begin{document}\ttfamily \begin{minipage}[t]{1mm} 1 x x x - x - x \fbox{-} \fbox{x} \end{minipage} \hfill \begin{minipage}[t]{3mm} 3 x x x {-} x - x \fbox{-} \fbox{x} \end{minipage} \end{document} _______________________________________________ TeX-NL mailing list TeX-NL@ntg.nl mailto:TeX-NL@ntg.nl http://www.ntg.nl/cgi-bin/mailman/listinfo/tex-nl

_______________________________________________ TeX-NL mailing list TeX-NL@ntg.nl http://www.ntg.nl/cgi-bin/mailman/listinfo/tex-nl

-- Wybo

Ik heb de test met xelatex + DejaVu Sans Mono gedaan, en met pdflatex + tgtermes en in beide gevallen kan ik geen verschil ontdekken tussen de twee kolommen dus ik vraag me af wat jullie precies bedoelen? Kan iemand ergens een PDF uploaden om het te laten zien? Het is misschien een hele stomme opmerking, maar ik neem aan dat in LaTeX het afbreek-teken een andere interne codering heeft dan een min-teken. Ik kan me ook voorstellen dat in veel gevallen het afbreek-teken en het min-teken met hetzelfde symbool (liggend streepje) kunnen worden gerepresenteerd, en dat daardoor LaTeX in sommige gevallen denkt dat een min-teken eigenlijk een afbreek-teken is? Groeten, Wilfred ________________________________ From: Wybo Dekker To: tex-nl@ntg.nl Sent: Friday, 24 February 2012, 21:57 Subject: Re: [Tex-nl] Fontafhankelijke ongewenste extra witregel na minteken Hans Hagen kwam met het voorstel om \begin{minipage}{1mm}...\end{minipage} te vergelijken met \vbox\bgroup\hsize1mm...\egroup En dan blijkt dat in die laatste vorm het probleem niet optreedt, zie de test hieronder. Zijn volgende suggestie was dan maar aan de minipage-omgeving te gaan knutselen, maar dat gaat me toch wat ver. Ik denk dat we Piet van Oostrum weer even nodig hebben...: \documentclass[12pt]{article} \usepackage[papersize={30mm,60mm},noheadfoot,margin=5mm]{geometry} \usepackage{DejaVuSansMono} \parindent0pt\pagestyle{empty} \begin{document}\ttfamily \begin{minipage}[b]{1mm} x x x - x - x x \end{minipage} \hfill \vbox\bgroup\hsize1mm x x x - x - x x \egroup \end{document} On 2012-02-23 17:12, Pander wrote:

Hoi allemaal,

Met sommige fonts ontstaat er een extra witregel bij specifiek gebruikt van een los minteken.

Wybo en ik hebben dit onderzocht en het is een hele lastige. Waarschijnlijk heeft het met woordafbreken te maken. Het is iets dat alleen bij sommige fonts optreed maar het ligt niet aan die fonts zelf maar hoe TeX hier mee omgaat.

Steve White van GNU FreeFont heeft hiervoor naar de fonts gekeken en dit bevestigd. Een workaround voor deze gevallen is een mbox of fbox maar er moet een robuuste oplossing voor gevonden worden. Het is reproduceerbaar in XeLaTeX, PDFLaTeX en LaTeX.

Hieronder is het minimale voorbeeld voor TeX dat Wybo heeft gemaakt. Wie van de TeX-experts weet dit op te lossen?

Groetjes,

Pander

\documentclass[draft,12pt]{article} \usepackage[papersize={30mm,70mm},noheadfoot,margin=5mm]{geometry} \usepackage{longtable} \usepackage{DejaVuSansMono} \parindent0pt\pagestyle{empty} \fboxsep0mm\fboxrule.01mm \begin{document}\ttfamily \begin{minipage}[t]{1mm} 1 x x x - x - x \fbox{-} \fbox{x} \end{minipage} \hfill \begin{minipage}[t]{3mm} 3 x x x {-} x - x \fbox{-} \fbox{x} \end{minipage} \end{document} _______________________________________________ TeX-NL mailing list TeX-NL@ntg.nl http://www.ntg.nl/cgi-bin/mailman/listinfo/tex-nl

-- Wybo _______________________________________________ TeX-NL mailing list TeX-NL@ntg.nl http://www.ntg.nl/cgi-bin/mailman/listinfo/tex-nl

In een minipage wordt de \emergencystretch gezet. Gewoon om de afbreking een handje te helpen als de minipage erg small is. De afbreking doet dan nog een derde ronde als er met de eerste twee passes geen gunstig resultaat behaald wordt. De emergencystretch geeft dan aan hoeveel een regel extra opgerekt mag worden denk ik. Als je in de minipage \emergencystretch=0pt zet wordt alles weer normaal (t/m 3pt ook nog). Waarom die derde pass bij een -teken een extra regel invoegt is me nog niet duidelijk. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]

On 25-2-2012 23:25, Piet van Oostrum wrote:

Als ik het voorbeeld met lualatex draai dan is alles normaal, d.w.z. minpage en vbox geven hetzelfde resultaat. Zou er dan toch een rariteit in de afbreekalgoritme (emergencypass) zitten die er in luatex uitgehaald is? Ook met plain tex en vboxen met/zonder emergencystretch zie je hetzelfde. Gewoon tex geeft de extra regels en luatex niet. Kennelijk vindt de originele afbreekalgoritme in het geval van een emergencystretch een afbreking die met een extra lege regel achter een -teken "optimaler" is dan zonder die extra regel.

Misschien kan Taco wat licht hierop laten schijnen?

Hoi Piet, Hyphenation gaat anders in luatex. Afgezien van wat details in patronen, is de afbreekfase nu een aparte en niet geintegreerd in de par builder. De hele node list wordt op een gegeven moment van afbreekpunten voorzien en Verder zijn we wat meer instelmogelijkheden: [pre|post] [ex] hyphenchar enz. Wat betreft de 'verwerking' zijn er wat dingen aangepast (hieronder geeft een indicatie). De parbuilder code is wat complex omdat er natuurlijk l2r en r2l mix mogelijk is, wiskunde in kan zitten, hz en protrusion een rol spelen, etc. Verder zijn de drie passes verweven in een serie loops. ==== uit de luatex manual ==== \chapter[languages]{Languages and characters, fonts and glyphs} .... In \LUATEX, the situation is quite different. The characters you type are always converted into \type{glyph_node} records with a special subtype to identify them as being intended as linguistic characters. \LUATEX\ stores the needed language information in those records, but does not do any font|-|related processing at the time of node creation. It only stores the index of the font. When it becomes necessary to typeset a paragraph, \LUATEX\ first inserts all hyphenation points right into the whole node list. Next, it processes all the font information in the whole list (creating ligatures and adjusting kerning), and finally it adjusts all the subtype identifiers so that the records are \quote{glyph nodes} from now on. .... \section{The main control loop} In \LUATEX's main loop, almost all input characters that are to be typeset are converted into \type{glyph_node} records with subtype \quote{character}, but there are a few small exceptions. .... Fourth, automatic discretionaries are handled differently. \TEX82 inserts an empty discretionary after sensing an input character that matches the \tex{hyphenchar} in the current font. This test is wrong, in our opinion: whether or not hyphenation takes place should not depend on the current font, it is a language property. In \LUATEX, it works like this: if \LUATEX\ senses a string of input characters that matches the value of the new integer parameter \tex{exhyphenchar}, it will insert an explicit discretionary after that series of nodes. Initex sets the \tex{exhyphenchar=`\-}. Incidentally, this is a global parameter instead of a language-specific one because it may be useful to change the value depending on the document structure instead of the text language. Note: as of \LUATEX\ 0.63.0, the insertion of discretionaries after a sequence of explicit hyphens happens at the same time as the other hyphenation processing, {\it not\/} inside the main control loop. The only use \LUATEX\ has for \tex{hyphenchar} is at the check whether a word should be considered for hyphenation at all. If the \tex{hyphenchar} of the font attached to the first character node in a word is negative, then hyphenation of that word is abandoned immediately. {\bf This behavior is added for backward compatibility only, and the use of \type{\hyphenchar=-1} as a means of preventing hyphenation should not be used in new \LUATEX\ documents.} .... Finally, there is no longer a \type{main_loop} label in the code. Remember that \TEX82 did quite a lot of processing while adding \type{char_nodes} to the horizontal list? For speed reasons, it handled that processing code outside of the \quote{main control} loop, and only the first character of any \quote{word} was handled by that \quote{main control} loop. In \LUATEX, there is no longer a need for that (all hard work is done later), and the (now very small) bits of character-handling code have been moved back inline. When \tex{tracingcommands} is on, this is visible because the full word is reported, instead of just the initial character. etc ==== ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On 2-3-2012 16:56, Pander wrote:

On 2012-02-26 17:16, Hans Hagen wrote:

...

On 25-2-2012 23:25, Piet van Oostrum wrote:

....

Hallo allemaal,

Bedankt voor de nauwkeurige analyse tot zo ver. Moet deze discussie niet groter getrokken worden op een internationale TeX mailinglist?

Ik kwam het probleem initieel tegen met XeLaTeX in longtable en momenteel kan uit de voeten met de workaround van Wybo. Mijn vraag is dus welke mensen moeten hierbij betrokken worden voor een uiteindelijke bugfix?

Ik denk niet dat hier iets gefixed gaat worden want het is geen bug maar een neveneffect. Je kunt je zelfs afvragen of het niet gewoon correct is omdat een lege pre-discretionary component bij gebrek aan ruimte gewoon op een eigen regel komt als er nauwelijks breedte beschikbaar is en er een flinke emergencystretch cq tolerance is ingesteld. Verder is een losse hyphen betekenisloos (en zal met eerder een endash of zo verwachten). Er zijn wel meer bordercases. En het zou me niets verbazen als er in table mechanismes ook allerlei gemanipuleer van parameters plaatsvindt dat eea beinvloed maar mijn latex kennis is nihil. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Wybo Dekker schreef:

het ontgaat me wat je hier bedoelt. Er staat gewoon een min-teken, ASCII 0x2D. Wat niet wegneemt dat TeX dat een speciale behandeling zou kunnen geven omdat het een afbreekpunt kan zijn.

TeX voegt achter de hyphen (-) een \discretionary in. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]

Dank Piet, helemaal helder. Alleen: je zegt dat TeX die \discretionary toevoegt. Bedoel je niet LaTeX? Want in een \vbox treedt het probleem niet op, terwijl die, voor x-x bijvoorbeeld, wel netjes aan afbreken doet. Is het dus niet een latex-bug? En waar het ook gebeurt - het is toch niet logisch een \discretionary toe te voegen aan een - als die eindstandig is? Nog ter aanvulling: hetzelfde probleem is te zien in tabulars en longtables met een te smalle kolom. On 2012-02-26 00:25, Piet van Oostrum wrote:

Nog een paar stapjes verder:

Wat TeX doet is achter het -teken (wanneer dit het hyphenteken van het font is) een \discretionary{}{}{} toevoegen. Je krijgt het verschijnsel dus ook als je in plaats van een -teken de tekst b\discretionary{}{}{} gebruikt.

Als je het iets algemener neemt: b\discretionary{c}{d}{e} De discretionary zegt dat als er op die plek afgebroken wordt dan wordt de c gebruikt voor de afbreking (dus aan het eind van de regel) en d op de volgende regel. De e wordt gebruikt als er niet afgebroken wordt. In ons geval met de superkorte regels wordt na deze d natuurlijk weer afgebroken. Als de regels wat groter zouden zijn dan zou de volgende x er ook nog bij passen.

Met de kleine breedte en de tekst b\discretionary{c}{d}{e} is het duidelijk dat er tussen de c en de d afgebroken wordt. Je krijgt dan dus:

x bc d x

(Als de minipage wat breder was geweest dan zou de x achter de d staan.)

Echter met c en d leeg breekt hij dus ook op dit punt af en je krijgt dan dus:

x b

x

Waarom een afbreking daar beter zou zijn dan geen afbreking is niet helemaal duidelijk. Het kan zijn dat die afbreking evenveel penalty veroorzaakt als niet afbreken en dat wel afbreken toevallig gekozen wordt.

In een normale minipage zou je het verschijnsel niet merken omdat de x dan achter de lege tweede parameter van de \discretionary komt te staan en alles daarom normaal lijkt. Als je de breedte van de minipage op de breedte van de x zet is er al niks meer aan de hand. Zie dit voorbeeld:

\newlength{\minipagewidth} \settowidth{\minipagewidth}{x} \begin{minipage}[b]{\minipagewidth} m x x b\discretionary{c}{}{e} x - x x \end{minipage}

-- Wybo

Piet van Oostrum schreef:

Nee, het is een puur TeX probleem. Je kunt hetzelfde effect bereiken met plain TeX, met een \vbox met of zonder \emergencystretch. In het TeXbook hoofdstuk 14 staat het beschreven. Dat het in een pure \vbox niet optreedt is omdat \emergencystretch dan 0pt is.

De \discretionary die na een - toegevoegd wordt zorgt ervoor dat het een mogelijk afbreekpunt wordt. Anders was de - een gewoon teken net als alle andere.

Mijn zinnen waren een beetje door elkaar gehutseld. Het moest zijn: Nee, het is een puur TeX probleem. Je kunt hetzelfde effect bereiken met plain TeX, met een \vbox met of zonder \emergencystretch. Dat het in een pure \vbox niet optreedt is omdat \emergencystretch dan 0pt is. \parindent=0pt\tracingall \vbox\bgroup\hsize1mm\emergencystretch10pt 1 x x - x - x x \egroup \hskip 2cm \vbox\bgroup\hsize1mm 2 x x - x - x x \egroup \bye In het TeXbook hoofdstuk 14 staat het beschreven. De \discretionary die na een - toegevoegd wordt zorgt ervoor dat het een mogelijk afbreekpunt wordt. Anders was de - een gewoon teken net als alle andere. -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]

Wybo Dekker schreef:

Hans Hagen kwam met het voorstel om \begin{minipage}{1mm}...\end{minipage} te vergelijken met \vbox\bgroup\hsize1mm...\egroup En dan blijkt dat in die laatste vorm het probleem niet optreedt, zie de test hieronder. Zijn volgende suggestie was dan maar aan de minipage-omgeving te gaan knutselen, maar dat gaat me toch wat ver. Ik denk dat we Piet van Oostrum weer even nodig hebben...:

Ik ben net gisteren in Bolivia aangekomen na een reis van 38 uur. Ik moet even bijkomen voor ik me hier in ga storten. Groeten, -- Piet van Oostrum WWW: http://pietvanoostrum.com/ PGP key: [8DAE142BE17999C4]