@michal.h21 since the end result in the browser is more or less Unicode based as well, wouldn't it be possible at least in theory not to rely on luainputenc mapping to classic tex codes but to simply let utf8 data pass through?
@JosephWright like an 8bit engine with teh wrong patterns loaded;-) \showhyphens{straße}
@DavidCarlisle tex4ht needs the DVI format to work, and that's 8-bit
@DavidCarlisle Like I said, I suspect with LuaTeX it should be possible to remap the font positions to the Unicode ones, and the same with input encodings, and so everything can be Unicode (and so hyphenate correctly)
@JosephWright yes clarification for others, mostly (I'd been away from the screen and was just catching up quickly
@JosephWright but if you are assuming character data can just pass through it doesn't matter much what characters they are internally, could just take it as utf8 data and sort it out at the end. (But actually I thought dvi could use wider character formats, just tex didn't use them, or maybe I remembered that wrong)
@JosephWright yes we should look in to this after the release
@DavidCarlisle yes, it is a problem, I've tried some exercise yesterday, in hyphenate callback I translated T1 encoded chars to corresponding unicode chars, called lang.hyphenate function on the resulting node list. this didn't work, unfortunately.
when I left unicode chars in the nodes, the output was really wrong, which I expected. so I translated unicode chars back to T1 and correct glyphs were used, but hyphenation didn't work in either case
@DavidCarlisle yes, it is possible for example to use \newunicodechar to insert special tex4ht instructions with unicode hexadecimal entities, which are in later stages of conversion translated to unicode characters
@JosephWright I think it is really hard to find unicode values for 8-bit coded fonts, especially math and virtual ones
@JosephWright this is not a problem, we can encode unicode characters using callbacks. the problem is that tex4ht fails when it can't find a tfm file, which is the case with open type fonts. this is fixable, but first we need somebody, who understand Eitan's c code
@michal.h21 I mean that for a T1 encoded font we know what the semantics of the slots are and we know the equivalent semantics for Unicode code points, so it should be possible to alter how the mappings are done
@michal.h21 Isn't that though because it relies on DVI mode?
@michal.h21 I was thinking this should be handled by the font loader: I guess I'll have to ask Hans what they've done about this in ConTeXt
@michal.h21 I didn't think the DVI format would allow full Unicode working, hence XeTeX requiring xdv output
@JosephWright Well spotted with the fontspec version info. It may another change in fontspec that is at the root of this, as I believe the old option syntax is still accepted.
dvips: Font file:lmroman10-regular:script=latn;+trep;+tlig; not found; using cmr10
</home/mint/texlive/2012/texmf-dist/fonts/pk/ljfour/public/cm/dpi600/cmr10.pk> dvips: ! invalid char 345 from font file:lmroman10-regular:script=latn;+trep;+tlig;
I want to ask what could be problem with following code:
\documentclass{article}
\usepackage{printsudoku}
\usepackage{solvesudoku}
\usepackage{createsudoku}
\begin{document}
\sudoku{test01.sud}
\end{document}
I am using Texmaker as my editor and I have installed MiKTeX on windows. The erro...
@karlkoeller in this case I mean it:-) "neither" is a tricky construct and apart from "use what sounds right" I'm not sure what method I would use to choose
@PauloCereda He rummaged for half an hour in my gums and used a drill. I have a couple of teeth to extract and some other jobs. :( Not ending before September.
Is it possible to identify the font used in a specific document/picture?
Answers to this question should identify:
Possible methods to do this (perhaps one answer per method) and adequately describe how to use it (as opposed to merely stating it);
Ways of finding the identified fonts, if possi...