Re: [XeTeX] Linux Libertine 5 serif too heavy
Hi, It seems like there have been problems with downloading the archive from SourceForge. Last time I tried the archive was broken: viz. [GlenMorangie:~/Downloads] rossmoor% tar tf LinLibertineFont-4.4.1.tar use the latex version on ctan ftp://dante.ctan.org/tex-archive/fonts/libertine/ with the actual fonts. version 5.1.2 ftp://dante.ctan.org/tex-archive/fonts/libertine/fonts/opentype/public/libertine/ By Michael -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Linux Libertine 5 serif too heavy
Hi, thans for your reply. Actually, with version LinLibertine_Re-4.7.5.otf I do get the desired output. That's why I'm so confused. use the actual version! ftp://dante.ctan.org/tex-archive/fonts/libertine/ By Michael -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Linux Libertine 5 serif too heavy
Hi,
I tried the new version 5 of the Linux Libertine font. I'm getting a way to
heavy serif font. Could someone please check if this a problem with my setup
or a real problem?
Thanks,
Sebastian
\documentclass[fontsize=12pt]{scrartcl}
\usepackage{fontspec}
\setmainfont{Linux Libertine O}
if you use only fontspec and setmainfont you get not all font
series/shapes.
Use \usepackage{libertine} instead.
\listfiles
\XeTeXtracingfonts=1
\documentclass{article}
\usepackage{libertine}
\pagestyle{empty}
\begin{document}
Test mit Libertine
\textit{Test mit Libertine}
\textbf{bold}
\textbf{bold \textit{italic}}
\textsb{semi bold}
\textsb{semi bold \textit{italic}}
verylongword\\\it{verylongword}\\{\itshape verylongword}
\end{document}
> pdffonts test.pdf
name type emb sub uni object ID
- --- --- --- -
DKBSSJ+LinLibertineO-Identity-H CID Type 0C yes yes yes 5 0
HYDZTA+LinLibertineOI-Identity-H CID Type 0C yes yes yes 7 0
VWYYRU+LinLibertineOB-Identity-H CID Type 0C yes yes yes 9 0
PQGWDP+LinLibertineOBI-Identity-HCID Type 0C yes yes yes 11 0
AXUNFG+LinLibertineOZ-Identity-H CID Type 0C yes yes yes 13 0
PJQSDK+LinLibertineOZI-Identity-HCID Type 0C yes yes yes 15 0
(/usr/local/texlive/2010/../texmf-local/tex/latex/libertine/libertine.sty
Package: libertine 2011/06/06 - 5.1.2: Font libertine - (License GPL)
Michael N
iedermair
By
Michael
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Linux Libertine 5 serif too heavy
Hi David, On 14/06/2011, at 11:15 AM, David J. Perry wrote: > Ross, > > It looks like you may have multiple versions of Libertine. The list of fonts > at the left of your screen shot shows Linux Libertine O, which is the > opentype version (fonts endings in .otf), while the main portion shows .ttf > fonts, which are named Linux Libertine (no 'O'). I had the same problem a > while back, accidentally having installed both versions. Thanks for the suggestion. It seems like there have been problems with downloading the archive from SourceForge. Last time I tried the archive was broken: viz. [GlenMorangie:~/Downloads] rossmoor% tar tf LinLibertineFont-4.4.1.tar LinLibertineFont/ LinLibertineFont/Biolinum_Re-0.4.1.ttf LinLibertineFont/LinLibertineC_Re-4.0.3.ttf LinLibertineFont/Readme-TEX.txt LinLibertineFont/LinLibertine_Re-4.4.1.otf LinLibertineFont/LinLibertine_It-4.0.6.ttf LinLibertineFont/Readme LinLibertineFont/LinLibertineC_Re-4.0.3.otf LinLibertineFont/LICENCE.txt LinLibertineFont/ChangeLog.txt LinLibertineFont/LinLibertine_BI-4.0.5.ttf LinLibertineFont/LinLibertine_BI-4.0.5.otf LinLibertineFont/GPL.txt LinLibertineFont/LinLibertine_Re-4.4.1.ttf tar: Truncated input file (need to skip 512 bytes) tar: Error exit delayed from previous errors. There is no purely italic version in there. Who knows how much of the archive is missing! > Go with one or the other and see if that helps. Maybe Sebastian has the > same issues. I think it is time to try to get the archive afresh. > > Best wishes, > David Cheers, Ross Ross Moore ross.mo...@mq.edu.au Mathematics Department office: E7A-419 Macquarie University tel: +61 (0)2 9850 8955 Sydney, Australia 2109 fax: +61 (0)2 9850 8114 -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Linux Libertine 5 serif too heavy
Ross,
It looks like you may have multiple versions of Libertine. The list of
fonts at the left of your screen shot shows Linux Libertine O, which is the
opentype version (fonts endings in .otf), while the main portion shows .ttf
fonts, which are named Linux Libertine (no 'O'). I had the same problem a
while back, accidentally having installed both versions. Go with one or the
other and see if that helps. Maybe Sebastian has the same issues.
Best wishes,
David
- Original Message -
From: "Ross Moore"
To: "Unicode-based TeX for Mac OS X and other platforms"
Sent: Monday, June 13, 2011 5:53 PM
Subject: Re: [XeTeX] Linux Libertine 5 serif too heavy
Hello Sebastien,
On 14/06/2011, at 6:38 AM, Sebastian Gerecke wrote:
Hi,
I tried the new version 5 of the Linux Libertine font. I'm getting a way
to
heavy serif font. Could someone please check if this a problem with my
setup
or a real problem?
It happens with earlier versions too.
Although there are .ttf files for 4 styles,
only Regular and Bold Italic and condensed are actually
accessible to the OS and XeTeX. (see attached image)
Dunno why, sorry.
Thanks,
Sebastian
\documentclass[fontsize=12pt]{scrartcl}
\usepackage{fontspec}
\setmainfont{Linux Libertine O}
\begin{document}
verylongword \it{verylongword} {\itshape verylongword}
\end{document}
<124.pdf>
Hope someone can look into this.
Cheers,
Ross
Ross Moore ross.mo...@mq.edu.au
Mathematics Department office: E7A-419
Macquarie University tel: +61 (0)2 9850 8955
Sydney, Australia 2109 fax: +61 (0)2 9850 8114
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Linux Libertine 5 serif too heavy
Am Dienstag, 14. Juni 2011, 07:53:25 schrieb Ross Moore: > Hello Sebastien, > > I tried the new version 5 of the Linux Libertine font. I'm getting a way > > to heavy serif font. Could someone please check if this a problem with > > my setup or a real problem? > > It happens with earlier versions too. Hi Ross, thans for your reply. Actually, with version LinLibertine_Re-4.7.5.otf I do get the desired output. That's why I'm so confused. Sebastian 124-old.pdf Description: Adobe PDF document -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Problem with ocrb10.otf ligature 'fi'
On 2011-06-13 at 08:34:15 -0500, msk...@ansuz.sooke.bc.ca wrote: > On Mon, 13 Jun 2011, Pander wrote: > > Would it also be possible to generate Bold, Italic, Light and > > Condensed versions for OCR-A and OCR-B? In that way it is also > > backwards compatible with the current OCRA fonts. > > Someone could no doubt design bold, italic, light, and condensed > fonts that visually resembled OCR-A and OCR-B, but I think it would > be irresponsible to call such fonts OCR-A and OCR-B. Bear in mind > that OCR-A and OCR-B exist for the specific purpose of automated > character recognition. They are written up in standards documents, > and hardware and software are designed specifically to handle not > only those letter shapes, but also specific sizes, spacing, and so > on. If we start extending the standard in non-standard ways to > include extra glyphs, extra styles, and so on, then the result will > no longer be within the specifications of the systems that are > designed to use these fonts. Condensed would be especially likely > to be a problem. Maybe for graphic design reasons it would be > desirable to have fonts for human-only consumption that look "like > OCR fonts, but different"; but those will no longer be OCR fonts > and I'd prefer to avoid confusion as much as possible. What you say is exactly what I think. I'd like to see your fonts on CTAN. Nice that you already provide OTF. Regards, Reinhard -- Reinhard Kotucha Phone: +49-511-3373112 Marschnerstr. 25 D-30167 Hannover mailto:reinhard.kotu...@web.de Microsoft isn't the answer. Microsoft is the question, and the answer is NO. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Mongolian
On Mon, Jun 13, 2011 at 16:20, Danyll Wills wrote: > Жаргал-аа, Саин байна үү? Or should I say 'Привет'? :-) > > Are you familiar with Montex? I have been working with it for many years. Just a note. From what I understand montex only works with 8bit engines. The author is planning to extend support to XeTeX, but he is a bit busy and hardly finds any time. Mojca -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Mongolian
Жаргал-аа, Саин байна үү? Or should I say 'Привет'? :-)
Are you familiar with Montex? I have been working with it for many years. I
made some very minor changes and it works on my Mac. Recently, however, I have
had a problem. In the past, I was able to get the latest TeXShop and redo
Montex. The last time I tried, it all seemed to work and I could compile files
in TeXShop and I would get the vertical Uighur script. Now, however, I follow
all the instructions, the code is fine, the file is fine, but when I look at it
outside of TeXShop, the fonts are gone! I have not yet worked out why.
If you would like to play around with it, download it from here:
http://userpage.fu-berlin.de/~corff/im/MLS/montex.html
I might be able to remember what I did to make it work. I think I changed one
or two files. I could send them to you if you want them.
Good luck with it!
Danyll (In Hong Kong)
On 6 Jun 2011, at 2:06 , Жаргал Бадагаров wrote:
> Hi Gareth!
>
> Thank you so much! I will take closer look at this tomorrow. Apparently the
> Code2000 font has many drawbacks.
>
>
> Best regards,
> Jargal
>
> -Original Message-
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 05/06/11 09:53, Жаргал Бадагаров wrote:
>>> Hello members,
>>>
>>>
>>> My name is Jargal. I am interested in the Mongolian Vertical Script Support
>>> in MacOS. I have found a 2005 presentation of XETEX made in Uhan, where it
>>> is said that Mongolian had not yet obtained a full support of all its
>>> features.
>>>
>>> Do you know if it has been being developed so far? Any advancements for the
>>> Mongolian Script Support? Any information would be highly appreciated as I
>>> am quite a newbee in the field of unix/linux and macos,
>>>
>>> Thank you and have a good day!
>>>
>>> Jargal Badagarov
>>>
>>
>> Dear Jargal,
>>
>> Welcome! I know absolutely no Mongolian, but I made decorative use of
>> the vertical script in a poster for a seminar I gave on a couple of
>> 13th-century ?ng?t monks. The PDF can be seen at
>> http://www.garzo.co.uk/documents/poster.pdf. I've attached the source
>> file. As you can see, I've used Code2000, which is not a specialist
>> Mongolian font, but does the trick (I hope!). The XeTeX manual has
>> instructions for writing vertical Chinese, which can be followed. As you
>> can see \rotatebox{-90} is used to turn the text to vertical. I hope
>> that helps a little. Maybe someday I shall learn some beautiful Mongolian!
>>
>> Best wishes,
>>
>> Gareth.
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.6 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iD8DBQFN67Ew9UDttp8yrx4RAjBpAKCVH7d3BRb4mnoE2yn1ZRH3QjTq1ACgp957
>> TooHrEn35OejTn1t674a5J8=
>> =DWF1
>> -END PGP SIGNATURE-
>>
>> ATTACHMENT: text/x-tex (poster.tex)
>>
>>
>> --
>> Subscriptions, Archive, and List information, etc.:
>> http://tug.org/mailman/listinfo/xetex
>>
>>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
> http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Problem with ocrb10.otf ligature 'fi'
2011/6/13 Pander : > On 2011-06-13 15:27, Zdenek Wagner wrote: >> 2011/6/13 Pander : >>> TeX Live list members: see full thread here: >>> http://tug.org/pipermail/xetex/2011-June/020681.html for now keep the >>> discussion at XeTeX's list. >>> >>> On 2011-06-13 14:22, msk...@ansuz.sooke.bc.ca wrote: On Mon, 13 Jun 2011, Pander wrote: > TeX Live 2010 > > /usr/local/texlive/2010/texmf-dist/fonts/opentype/public/ocr-b-outline/ocrb10.otf That is Zdeněk Wagner's auto-conversion of Norbert Schwarz's Metafont source. It doesn't contain f-ligatures no matter what the GSUB table may say. I took a look at it with Fontforge and I see that it contains a GSUB table pointing the ligatures at "alternate" and added non-ASCII characters from the Schwarz version, some of which happen to be ligature-like but not the correct ones. For instance, "fl" points at the Æ glyph. I recogize that pattern because it happened in an earlier version of my own version of the font, as a result of auto-conversion. The thing is, Schwarz's Metafont files used a nonstandard custom encoding. If you simply convert the font code point for code point to whatever the default 8-bit Adobe encoding might be, you end up with Schwarz's extra glyphs at the "f-ligature" code points (as well as some distortions at quotation mark, dotless i and j, and similar code points). The existence of a GSUB table pointing at those points can probably be explained by defaults from the auto-conversion. So in summary, yes, it's a bug in the font. >>> >>> Could the conversion software generate a warning when it recognises such >>> a situation? >>> >> The fonts were first converted to PFB by mftrace, then opened in >> FontForge and saved as OTF. No warning was displayed. > > Sorry, I mean, should those software packages be improved to generate > warnings for these kind of situations to prevent it in the future? > Yes, it would certainly be helpful. Since mftrace is a python script running mf and potrace together with (or inside of) FontForge, it should probably be reported to FontForge developers. I do not know pythom myself, I am not a font expert, I just used the tool as a black box. -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with ocrb10.otf ligature 'fi'
On Mon, 13 Jun 2011, Pander wrote: > And Ubuntu should also switch to these OCRA fonts for ttf-ocr-a? What is > in there is from 2009 and is credited to > "Created by Sauter,U-TOWN_HALL\Sauter,S-1-5-21-2526881554-1349 with > FontForge 1.0 (http://fontforge.sf.net)" OCR-A is another question. I combined OCR-A and OCR-B in my own package, but the designs are independent and most other packages just do one or the other. I believe John Sauter's version is still actively maintained, and if there are bugs in it he'll probably be interested in fixing them. He's certainly been actively maintaining the Wikipedia page about OCR-A, which may or may not be in line with Wikipedia's rules, but I have no objection to it. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with ocrb10.otf ligature 'fi'
On Mon, 13 Jun 2011, Pander wrote: > > mark, dotless i and j, and similar code points). The existence of a GSUB > > table pointing at those points can probably be explained by defaults from > > the auto-conversion. So in summary, yes, it's a bug in the font. > > Could the conversion software generate a warning when it recognises such > a situation? That would be very difficult, because the conversion software has no way of knowing that the glyph its user said was "ffl" isn't really. > > The current version of my own OCR B fonts, available on ansuz.sooke.bc.ca, > > http://ansuz.sooke.bc.ca/page/fonts I haven't tried to get this package put into TeXLive because I see it as still being sort of beta (in particular, the nonstandard versions of OCRB aren't debugged and distributed yet), but if there's interest I might pursue fixing the remaining issues. Of course TeXLive is free to distribute it at any time if they do whatever packaging work is needed to make that happen. > In effect it is freeware and is owned by Barcodesoft. But according to > your README, one is allowed to redistribute this and your enhanced > version. So in the same way would TeX Live be able to so. The metadata > in the font files provides proper credits. There are four different packages here and I think you may be confusing two of them: 1. Norbert Schwarz's version (currently on CTAN, probably also in TeXLive) 2. Zdeněk Wagner's version (in TeXLive) 3. Mine (not in TeXLive) 4. Barcodesoft's version Numbers 2 and 3 are both based on number 1, and all three of those are free and could be included in TeXLive. Number 4 is a watermarked commercial demo, as far as I know unconnected to the other three. Even if its purveyors would be happy to have it distributed, I think distributing it would be a bad idea because it's of inferior quality (because of the watermarks) compared to the free ones, and distributing a commercial advertisement for something that ought to be available free of charge is ideologically objectionable. > Would it also be possible to generate Bold, Italic, Light and Condensed > versions for OCR-A and OCR-B? In that way it is also backwards > compatible with the current OCRA fonts. Someone could no doubt design bold, italic, light, and condensed fonts that visually resembled OCR-A and OCR-B, but I think it would be irresponsible to call such fonts OCR-A and OCR-B. Bear in mind that OCR-A and OCR-B exist for the specific purpose of automated character recognition. They are written up in standards documents, and hardware and software are designed specifically to handle not only those letter shapes, but also specific sizes, spacing, and so on. If we start extending the standard in non-standard ways to include extra glyphs, extra styles, and so on, then the result will no longer be within the specifications of the systems that are designed to use these fonts. Condensed would be especially likely to be a problem. Maybe for graphic design reasons it would be desirable to have fonts for human-only consumption that look "like OCR fonts, but different"; but those will no longer be OCR fonts and I'd prefer to avoid confusion as much as possible. Some of the existing fonts already include nonstandard glyphs and styles. My own approach in creating my package was to preserve what existed in my inputs (some of which are currently to-do items rather than being in the distributed package) and fix obvious bugs like the encoding, but not add anything new myself. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Problem with ocrb10.otf ligature 'fi'
On 2011-06-13 15:27, Zdenek Wagner wrote: > 2011/6/13 Pander : >> TeX Live list members: see full thread here: >> http://tug.org/pipermail/xetex/2011-June/020681.html for now keep the >> discussion at XeTeX's list. >> >> On 2011-06-13 14:22, msk...@ansuz.sooke.bc.ca wrote: >>> On Mon, 13 Jun 2011, Pander wrote: TeX Live 2010 /usr/local/texlive/2010/texmf-dist/fonts/opentype/public/ocr-b-outline/ocrb10.otf >>> >>> That is Zdeněk Wagner's auto-conversion of Norbert Schwarz's Metafont >>> source. It doesn't contain f-ligatures no matter what the GSUB table may >>> say. I took a look at it with Fontforge and I see that it contains a GSUB >>> table pointing the ligatures at "alternate" and added non-ASCII characters >>> from the Schwarz version, some of which happen to be ligature-like but not >>> the correct ones. For instance, "fl" points at the Æ glyph. >>> >>> I recogize that pattern because it happened in an earlier version of my >>> own version of the font, as a result of auto-conversion. The thing is, >>> Schwarz's Metafont files used a nonstandard custom encoding. If you >>> simply convert the font code point for code point to whatever the default >>> 8-bit Adobe encoding might be, you end up with Schwarz's extra glyphs at >>> the "f-ligature" code points (as well as some distortions at quotation >>> mark, dotless i and j, and similar code points). The existence of a GSUB >>> table pointing at those points can probably be explained by defaults from >>> the auto-conversion. So in summary, yes, it's a bug in the font. >> >> Could the conversion software generate a warning when it recognises such >> a situation? >> > The fonts were first converted to PFB by mftrace, then opened in > FontForge and saved as OTF. No warning was displayed. Sorry, I mean, should those software packages be improved to generate warnings for these kind of situations to prevent it in the future? -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] [tex-live] Problem with ocrb10.otf ligature 'fi'
2011/6/13 Pander : > TeX Live list members: see full thread here: > http://tug.org/pipermail/xetex/2011-June/020681.html for now keep the > discussion at XeTeX's list. > > On 2011-06-13 14:22, msk...@ansuz.sooke.bc.ca wrote: >> On Mon, 13 Jun 2011, Pander wrote: >>> TeX Live 2010 >>> >>> /usr/local/texlive/2010/texmf-dist/fonts/opentype/public/ocr-b-outline/ocrb10.otf >> >> That is Zdeněk Wagner's auto-conversion of Norbert Schwarz's Metafont >> source. It doesn't contain f-ligatures no matter what the GSUB table may >> say. I took a look at it with Fontforge and I see that it contains a GSUB >> table pointing the ligatures at "alternate" and added non-ASCII characters >> from the Schwarz version, some of which happen to be ligature-like but not >> the correct ones. For instance, "fl" points at the Æ glyph. >> >> I recogize that pattern because it happened in an earlier version of my >> own version of the font, as a result of auto-conversion. The thing is, >> Schwarz's Metafont files used a nonstandard custom encoding. If you >> simply convert the font code point for code point to whatever the default >> 8-bit Adobe encoding might be, you end up with Schwarz's extra glyphs at >> the "f-ligature" code points (as well as some distortions at quotation >> mark, dotless i and j, and similar code points). The existence of a GSUB >> table pointing at those points can probably be explained by defaults from >> the auto-conversion. So in summary, yes, it's a bug in the font. > > Could the conversion software generate a warning when it recognises such > a situation? > The fonts were first converted to PFB by mftrace, then opened in FontForge and saved as OTF. No warning was displayed. >> The current version of my own OCR B fonts, available on ansuz.sooke.bc.ca, > > http://ansuz.sooke.bc.ca/page/fonts > >> is also based on Schwarz's, but via a more manual conversion process >> (rewriting the Metafont sources to work with MetaType1), and I've >> attempted to put all glyphs at their correct Unicode code points. It >> contains a GSUB table for alternate forms of glyphs, but none for >> ligatures. >> I just downloaded the demo from here: http://www.barcodesoft.com/ocr_font.aspx >> >>> Maybe TeX Live should use these OTF files? >> >> Barcodesoft's "free" version is a watermarked demo of an expensive >> commercial product, basically just an advertisement, and for that reason I >> wouldn't recommend its distribution in TeXLive; I'm not even sure that the >> license agreement would allow such distribution. > > In effect it is freeware and is owned by Barcodesoft. But according to > your README, one is allowed to redistribute this and your enhanced > version. So in the same way would TeX Live be able to so. The metadata > in the font files provides proper credits. > > I think, first CTAN needs to be properly updated, see: > http://ctan.org/search/?search=ocr&search_type=description > Probably many of these CTAN package can merge. > > Subsequently TeX Live can do their update. For now, I'll forward this > also to them. > > Would it also be possible to generate Bold, Italic, Light and Condensed > versions for OCR-A and OCR-B? In that way it is also backwards > compatible with the current OCRA fonts. > If someone uploads better version of OCR-A and OCR-B fonts to CTAN, I won't mind if my fonts are deleted. I needed OCR-B for EAN13 only and have not tested them in other situations. -- Zdeněk Wagner http://hroch486.icpf.cas.cz/wagner/ http://icebearsoft.euweb.cz -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with ocrb10.otf ligature 'fi'
On 2011-06-13 14:56, Pander wrote: > TeX Live list members: see full thread here: > http://tug.org/pipermail/xetex/2011-June/020681.html for now keep the > discussion at XeTeX's list. > > On 2011-06-13 14:22, msk...@ansuz.sooke.bc.ca wrote: >> On Mon, 13 Jun 2011, Pander wrote: >>> TeX Live 2010 >>> >>> /usr/local/texlive/2010/texmf-dist/fonts/opentype/public/ocr-b-outline/ocrb10.otf >> >> That is Zdeněk Wagner's auto-conversion of Norbert Schwarz's Metafont >> source. It doesn't contain f-ligatures no matter what the GSUB table may >> say. I took a look at it with Fontforge and I see that it contains a GSUB >> table pointing the ligatures at "alternate" and added non-ASCII characters >> from the Schwarz version, some of which happen to be ligature-like but not >> the correct ones. For instance, "fl" points at the Æ glyph. >> >> I recogize that pattern because it happened in an earlier version of my >> own version of the font, as a result of auto-conversion. The thing is, >> Schwarz's Metafont files used a nonstandard custom encoding. If you >> simply convert the font code point for code point to whatever the default >> 8-bit Adobe encoding might be, you end up with Schwarz's extra glyphs at >> the "f-ligature" code points (as well as some distortions at quotation >> mark, dotless i and j, and similar code points). The existence of a GSUB >> table pointing at those points can probably be explained by defaults from >> the auto-conversion. So in summary, yes, it's a bug in the font. > > Could the conversion software generate a warning when it recognises such > a situation? > >> The current version of my own OCR B fonts, available on ansuz.sooke.bc.ca, > > http://ansuz.sooke.bc.ca/page/fonts > >> is also based on Schwarz's, but via a more manual conversion process >> (rewriting the Metafont sources to work with MetaType1), and I've >> attempted to put all glyphs at their correct Unicode code points. It >> contains a GSUB table for alternate forms of glyphs, but none for >> ligatures. >> I just downloaded the demo from here: http://www.barcodesoft.com/ocr_font.aspx >> >>> Maybe TeX Live should use these OTF files? >> >> Barcodesoft's "free" version is a watermarked demo of an expensive >> commercial product, basically just an advertisement, and for that reason I >> wouldn't recommend its distribution in TeXLive; I'm not even sure that the >> license agreement would allow such distribution. > > In effect it is freeware and is owned by Barcodesoft. But according to > your README, one is allowed to redistribute this and your enhanced > version. So in the same way would TeX Live be able to so. The metadata > in the font files provides proper credits. > > I think, first CTAN needs to be properly updated, see: > http://ctan.org/search/?search=ocr&search_type=description > Probably many of these CTAN package can merge. > > Subsequently TeX Live can do their update. For now, I'll forward this > also to them. > > Would it also be possible to generate Bold, Italic, Light and Condensed > versions for OCR-A and OCR-B? In that way it is also backwards > compatible with the current OCRA fonts. And Ubuntu should also switch to these OCRA fonts for ttf-ocr-a? What is in there is from 2009 and is credited to "Created by Sauter,U-TOWN_HALL\Sauter,S-1-5-21-2526881554-1349 with FontForge 1.0 (http://fontforge.sf.net)" These are the fonts: OCRALight:style=Light OCRACondensed:style=Condensed OCRAItalic:style=Italic OCRA:style=Medium OCRABold:style=Bold With this changelog: tf-ocr-a (1.0-2) unstable; urgency=low * Update my email address. * Change section to fonts. * Bump debhelper version. * Bump standards version. * Add Debian Fonts Task Force to Uploaders. * debian/copyright: Updated. -- Gürkan Sengün Wed, 05 Aug 2009 08:53:55 +0200 ttf-ocr-a (1.0-1) unstable; urgency=low * Initial release. (Closes: #452980) -- Gürkan Sengün Wed, 2 May 2007 16:17:15 +0200 It also has an interesting ReadMe.txt file So perhaps time to consolidate OCR-A and OCR-B in the different dictributions (TeX Live and Ubuntu) to those new ones? > >> >> >> >> >> >> -- >> Subscriptions, Archive, and List information, etc.: >> http://tug.org/mailman/listinfo/xetex > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with ocrb10.otf ligature 'fi'
TeX Live list members: see full thread here: http://tug.org/pipermail/xetex/2011-June/020681.html for now keep the discussion at XeTeX's list. On 2011-06-13 14:22, msk...@ansuz.sooke.bc.ca wrote: > On Mon, 13 Jun 2011, Pander wrote: >> TeX Live 2010 >> >> /usr/local/texlive/2010/texmf-dist/fonts/opentype/public/ocr-b-outline/ocrb10.otf > > That is Zdeněk Wagner's auto-conversion of Norbert Schwarz's Metafont > source. It doesn't contain f-ligatures no matter what the GSUB table may > say. I took a look at it with Fontforge and I see that it contains a GSUB > table pointing the ligatures at "alternate" and added non-ASCII characters > from the Schwarz version, some of which happen to be ligature-like but not > the correct ones. For instance, "fl" points at the Æ glyph. > > I recogize that pattern because it happened in an earlier version of my > own version of the font, as a result of auto-conversion. The thing is, > Schwarz's Metafont files used a nonstandard custom encoding. If you > simply convert the font code point for code point to whatever the default > 8-bit Adobe encoding might be, you end up with Schwarz's extra glyphs at > the "f-ligature" code points (as well as some distortions at quotation > mark, dotless i and j, and similar code points). The existence of a GSUB > table pointing at those points can probably be explained by defaults from > the auto-conversion. So in summary, yes, it's a bug in the font. Could the conversion software generate a warning when it recognises such a situation? > The current version of my own OCR B fonts, available on ansuz.sooke.bc.ca, http://ansuz.sooke.bc.ca/page/fonts > is also based on Schwarz's, but via a more manual conversion process > (rewriting the Metafont sources to work with MetaType1), and I've > attempted to put all glyphs at their correct Unicode code points. It > contains a GSUB table for alternate forms of glyphs, but none for > ligatures. > >>> I just downloaded the demo from here: >>> http://www.barcodesoft.com/ocr_font.aspx > >> Maybe TeX Live should use these OTF files? > > Barcodesoft's "free" version is a watermarked demo of an expensive > commercial product, basically just an advertisement, and for that reason I > wouldn't recommend its distribution in TeXLive; I'm not even sure that the > license agreement would allow such distribution. In effect it is freeware and is owned by Barcodesoft. But according to your README, one is allowed to redistribute this and your enhanced version. So in the same way would TeX Live be able to so. The metadata in the font files provides proper credits. I think, first CTAN needs to be properly updated, see: http://ctan.org/search/?search=ocr&search_type=description Probably many of these CTAN package can merge. Subsequently TeX Live can do their update. For now, I'll forward this also to them. Would it also be possible to generate Bold, Italic, Light and Condensed versions for OCR-A and OCR-B? In that way it is also backwards compatible with the current OCRA fonts. > > > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with ocrb10.otf ligature 'fi'
On Mon, 13 Jun 2011, Pander wrote: > TeX Live 2010 > > /usr/local/texlive/2010/texmf-dist/fonts/opentype/public/ocr-b-outline/ocrb10.otf That is Zdeněk Wagner's auto-conversion of Norbert Schwarz's Metafont source. It doesn't contain f-ligatures no matter what the GSUB table may say. I took a look at it with Fontforge and I see that it contains a GSUB table pointing the ligatures at "alternate" and added non-ASCII characters from the Schwarz version, some of which happen to be ligature-like but not the correct ones. For instance, "fl" points at the Æ glyph. I recogize that pattern because it happened in an earlier version of my own version of the font, as a result of auto-conversion. The thing is, Schwarz's Metafont files used a nonstandard custom encoding. If you simply convert the font code point for code point to whatever the default 8-bit Adobe encoding might be, you end up with Schwarz's extra glyphs at the "f-ligature" code points (as well as some distortions at quotation mark, dotless i and j, and similar code points). The existence of a GSUB table pointing at those points can probably be explained by defaults from the auto-conversion. So in summary, yes, it's a bug in the font. The current version of my own OCR B fonts, available on ansuz.sooke.bc.ca, is also based on Schwarz's, but via a more manual conversion process (rewriting the Metafont sources to work with MetaType1), and I've attempted to put all glyphs at their correct Unicode code points. It contains a GSUB table for alternate forms of glyphs, but none for ligatures. > > I just downloaded the demo from here: > > http://www.barcodesoft.com/ocr_font.aspx > Maybe TeX Live should use these OTF files? Barcodesoft's "free" version is a watermarked demo of an expensive commercial product, basically just an advertisement, and for that reason I wouldn't recommend its distribution in TeXLive; I'm not even sure that the license agreement would allow such distribution. -- Matthew Skala msk...@ansuz.sooke.bc.ca People before principles. http://ansuz.sooke.bc.ca/ -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] "Options for all fonts" : colo[u]r, and the transparency byte
Am 06.06.2011 um 09:33 schrieb Tobias Schoel:
3. xdvipmx and xdv2pdf convert TikZ's \special{}s into pdf
transparency on all systems.
Xdv2pdf seems to produce some strange PDF output on my system (Mac OS
X 10.5.8, PPC). The disdvi utility of TeX Live 2011 is able to
disassemble an XDV file (disdvi -x ).
--
Mit friedvollen Grüßen
Pete
The wise man said: "Never argue with an idiot. They bring you down to
their level and beat you with experience."
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with ocrb10.otf ligature 'fi'
On 2011-06-13 13:34, Peter Dyballa wrote: > > Am 12.06.2011 um 22:26 schrieb Pander: > >> I have discovered a problem with ocrb10.otf the ligatures are not workig >> correctly in xelatex. > > > /usr/local/texlive/2010/texmf-dist/fonts/opentype/public/ocr-b-outline/ocrb10.otf > *of course* does not have the f* ligatures. (You can check this easily > in some text editor, no ttx of fonttools necessary.) So what ttx is reporting below if of no use or erroneous? Because these ligature refer to glyphs that don't exist and causes the reported error. Would this be a bug report for ttx or for the maintainer of the font? for ttx it could be an option to not report references to glyph of which the glyph itself is not existing.> -- > Greetings > > Pete > > If my theory of relativity is proven successful, Germany will claim me > as a German, and France will declare that I am a citizen of the world. > Should my theory prove untrue, France will say that I am a German, and > Germany will declare that I am a Jew. > – Albert Einstein, 1929 > > > > > -- > Subscriptions, Archive, and List information, etc.: > http://tug.org/mailman/listinfo/xetex -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Problem with ocrb10.otf ligature 'fi'
Am 12.06.2011 um 22:26 schrieb Pander: I have discovered a problem with ocrb10.otf the ligatures are not workig correctly in xelatex. /usr/local/texlive/2010/texmf-dist/fonts/opentype/public/ocr-b-outline/ ocrb10.otf *of course* does not have the f* ligatures. (You can check this easily in some text editor, no ttx of fonttools necessary.) -- Greetings Pete If my theory of relativity is proven successful, Germany will claim me as a German, and France will declare that I am a citizen of the world. Should my theory prove untrue, France will say that I am a German, and Germany will declare that I am a Jew. – Albert Einstein, 1929 -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Persian verus Farsi
Bombay/Mumbai is a bit of a puzzle (to me, at least). As far as I know,
it's a Portuguese name originally ('good bay'), so what I take to be the
local pronunciation 'Mumbai' seems to be an approximation/corruption of that
rather than a reversion to an authentic original. My friend there (born and
bred in the city) insists on using 'Bombay' (in conversation though not on
his business card, I notice) but I haven't ventured to probe the reasons.
Possibly some people there regard Mumbai as a vulgarization? But I have no
command of Indic languages so someone may be able to put me right!
John
- Original Message -
From: "Philip TAYLOR (Webmaster, Ret'd)"
To: "Kamal Abdali"
Cc: "Unicode-based TeX for Mac OS X and other platforms"
Sent: 13 June 2011 08:37
Subject: Re: [XeTeX] Persian verus Farsi
Kamal Abdali wrote:
Names are a very sensitive matter. Just look at the large number of
countries and cities that have been renamed in the last 30 or so years:
Burma -> Myanmar, Ceylon -> Sri Lanka, Rhodesia -> Zimbabwe, Basutoland
-> Lesotho,
The last is interesting, in that it is pronounced very similarly
to the leading element in "Basuto-land", and not at all as one
might expect from the spelling; I suspect that both it and the
next :
Bombay -> Mumbai,
as well as Peking -> Beijing and Calcutta -> Kolkata, are more a
matter of trying to better approximate native pronunciation of the
name in a non-native script.
Madras -> Chennai. The new names were
adopted by popular demand because the older names were thought to have
been introduced by colonizers, occupiers, ruling elites, etc.
I think that "by popular demand" is highly unlikely; they were adopted
for the very reason that you give -- because the earlier names were
the creations of colonizers, occupiers, ruling elites, etc., but not
"by popular demand" -- rather by the wish (or whim) of a government
wishing to sweep away the old, tainted, names and replace them by
something more original and authentic.
Philip Taylor
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Persian verus Farsi
Kamal Abdali wrote: Names are a very sensitive matter. Just look at the large number of countries and cities that have been renamed in the last 30 or so years: Burma -> Myanmar, Ceylon -> Sri Lanka, Rhodesia -> Zimbabwe, Basutoland -> Lesotho, The last is interesting, in that it is pronounced very similarly to the leading element in "Basuto-land", and not at all as one might expect from the spelling; I suspect that both it and the next : Bombay -> Mumbai, as well as Peking -> Beijing and Calcutta -> Kolkata, are more a matter of trying to better approximate native pronunciation of the name in a non-native script. Madras -> Chennai. The new names were adopted by popular demand because the older names were thought to have been introduced by colonizers, occupiers, ruling elites, etc. I think that "by popular demand" is highly unlikely; they were adopted for the very reason that you give -- because the earlier names were the creations of colonizers, occupiers, ruling elites, etc., but not "by popular demand" -- rather by the wish (or whim) of a government wishing to sweep away the old, tainted, names and replace them by something more original and authentic. Philip Taylor -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
