On Tue, Jan 22, 2013 at 12:34 PM, Guenter Milde <mi...@users.sf.net> wrote:
> On 2013-01-21, Scott Kostyshak wrote:
>> On Mon, Jan 21, 2013 at 5:26 AM, Guenter Milde <mi...@users.sf.net> wrote:
>>> On 2013-01-21, Kornel Benko wrote:
>>>> Am Sonntag, 20. Januar 2013 um 18:54:51, schrieb Scott Kostyshak
>>>> <skost...@lyx.org>
>
>
>>>>> I am using TeX Live 2012. I get errors whether I set document encoding
>>>>> to Unicode (utf8) or not:
>
>>>>> ! Package inputenc Error: Unicode char \u8:Å not set up for use with
>>>>> LaTeX.
>
>>>>> ! Package inputenc Error: Unicode char \u8:ȷ not set up for use with
>>>>> LaTeX.
>
> ...
>
>>> OTOH, the errors should go away if you set the encdoing away from utf8, as
>>> "unicodesymbols" contains the translations ...
>
> ...
>
>>> Here, Math.lyx (from a recent git trunk checkout) compiles fine with my
>>> LyX 2.0.3 and output set to pdflatex.
>
>>> Hase there been a change in the default encoding?
>
>> A bisect
>
> Are you really sure you get the errors "whether I set document encoding
>>>>> to Unicode (utf8) or not:" ??
>
> The "Unicode char ... not set up for use ... is specific to
> inputencs "utf8" option.
If you're interested in this, let me know and I will compile a
previous version of trunk and confirm or disconfirm that this is the
case. Otherwise since Georg's recent commit fixed this for me I will
not look further into it.
Thanks,
Scott
>
>
>>> Anyway, if A WITH RING ABOVE and SMALL DOTLESS J are not defined for
>>> [utf8]{inputenc}, they should get a force flag in "unicodesymbols".
>
>>> However, testing here with inputenc from TeXLive 2012, I see only the
>>> error for dotless jot, while A with ring above and dotless i are fine.
>
> As Jürgen pointed out, Å is not Å (i.e. Angström is not A with ring).
>
> Both, dotless j and Å (Angström) should get force flags with utf8.
>
>> A git bisect leads me to the following:
>
>> commit 7c6a6a05a2410a2fcaaec7255c88ee5b554cbd67
>> Author: Georg Baum <b...@lyx.org>
>> Date: Sat Jan 12 19:25:24 2013 +0100
>
>> Fix bug #5087 as suggested by Jürgen
>
>> Now it is possible to force certain commands only for some encodings.
>
> I don't think this changed behaviour regarding this error, rather this
> existed for ages as unrecognized problem.
>
> Günter
>
