Re: [XeTeX] centering layout with geometry package
Am Sat, 26 Nov 2011 06:52:02 +0800 schrieb Daniel Greenhoe:
> I like your solution. But it seems it does not compile on my system.
> In particular, when I tried to compile using xelatex, it did not like
> \makeatletter (begin{document} no found) and \Gm. Is my system somehow
> different from yours?
Could be, show the log-file of your compilation.
But check at first if something did go wrong in the copy & paste.
Faulty line breaks or non-standard (invisible) space chars are often
the cause of "missing \begin{document}"-errors.
--
Ulrike Fischer
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] VIQR pre-processor wrotten in (Xe)TeX ?
2011/11/26 Vafa Khalighi :
> Sorry, I have not followed this discussion carefully on what others said but
> if all fails, I would use an external program (a per-processor) to do that.
> You can actually can make it automatic by just using the write18 feature of
> TeX. You write your tex document in VQR, then TeX calls your per-processor
> and converts your VQR to unicode and finally compiles your unicode TeX
> document, giving you PDF.
>
I did not follow the discussion because someone has already suggested
TECkit maps and it seemed to tme that the problem has been solved. Do
you need more complex preprocessing than just simple mapping of input
bytes to output bytes? I can imagine that it may be complex and cannot
be done in a simple step. You can look to the xetex-devanagari
package. The Velthuis maps were created by me. Vowels have to be
treated in a special way, viramas have to be inserted in between
consonants, thus I cannot do everything in a single step. Moreovever,
there is just a small difference between Sanskrit and Hindi, therefore
the Sanskrit map is essentially the Hindi map with one more step.
Maybe these samples can help you.
> On Sat, Nov 26, 2011 at 12:26 PM, Bruno Le Floch wrote:
>>
>> > Bruno Le Floch wrote:
>> >> Is it simply a matter of going through the string and replace various
>> >> characters by TeX accents (and take care of character order), or does
>> >> the result have to be Unicode?
>> >>
>> >> E.g., does it have to be a(a^ → ăâ, or can it be a(a^ → \u{a}\^{a} ?
>> >> If the second one is ok, then it shouldn't be too hard to write the
>> >> conversion in TeX macros. Please provide a list of the necessary
>> >> conversion rules.
>> >
>> > Vietnamese is difficult for TeX, because over a single
>> > character there can be a requirement for both an
>> > accent (to indicate a pronunciation different from
>> > that for the unaccented letter) and a tone marker
>> > (which applies to the whole word, but which has
>> > a canonical placement that may well be on an
>> > already accented letter). Hàn Thế Thành created
>> > a way of accomplishing this using standard TeX,
>> > but XeTeX can do it natively. Incidentally,
>> > the "ế" at the end of Thành's middle name demonstrates
>> > exactly the problem : something that TeX cannot
>> > accomplish without special fonts, since it has
>> > no primitive for positioning two diacritics over
>> > a single character.
>>
>> Thanks for the explanation. So we need to produce a Unicode string.
>>
>> Firstly, I should have asked: is it possible to require the Vietnamese
>> VIQR input as an argument of a macro, rather than being typeset
>> directly? e.g., \viqr{a^o' e\.}. I'll assume that it is ok.
>>
>> Then do you have a list of all Vietnamese characters and their VIQR
>> representation? Or some precise reference to what transformation you
>> want to apply? In particular, how many different characters do you
>> expect to get on output (that should be the size of the "alphabet")?
>>
>> Regards,
>> Bruno
>>
>>
>>
>> --
>> Subscriptions, Archive, and List information, etc.:
>> http://tug.org/mailman/listinfo/xetex
>
>
>
>
> --
> Subscriptions, Archive, and List information, etc.:
> http://tug.org/mailman/listinfo/xetex
>
>
--
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] centering layout with geometry package
2011/11/26 Daniel Greenhoe :
> I'm afraid I'm confused with regards to the zwpagelayout package. In
> the geometry package, there are two basic areas:
> 1. The physical page (e.g. a4 size paper)
> 2. The layout area (e.g. a5 size paper) that fits somewhere on the
> physical page
>
> By default, the two areas are identical, but they can be set
> differently. And all the basic parameters such as spacing for margins,
> header, footers, text area height and text area width ... they all
> refer to what is *inside* (not outside) the layout area.
>
> Is this same concept available in the zwpagelayout package? Or do the
> margin parameters refer to distance from the outside borders of the
> layout area to the borders of the physical page?
>
No, the concept is different. If you send the document to the
phototypesetter, you pay the amount of te film used. In order to
reduce the cost the physical size have to be as small as possible.
>From technological point of view the crop marks must have certain size
and a bleed area of certain size is required. As default these sizes
are set to 5mm because this is required by most print houses in the
Czech Republic. What you have to define are dimensions after trimming.
If the cropmarks option is set, the physical size of the media is set
so that it includes the bleed area (cropgap) and the area with the
crop marks (croplength). The boxes are set properly in PDF in xelatex
with xdvipdfmx, in pdflatex, and in latex+dvips. TrimBox is the box
containing the page after trimming. ArtBox is set to the same values,
BleedBox is set so that it includes the bleed area. MediaBox and
CropBox are not set by the package because they are set automatically
by the drivers using information on the paper size stored in
\paperwidth and \paperheight (these values are sent to the drivers).
It sometimes happen that I have A5 or B5 size document with crop marks
and I wish to print it centered on A4 using my laser printer. This can
be easily achieved by Acrobat Reader, it is just a matter of selecting
an option in the print dialogue. This is the reason why I do not set
the media size explicitely.
> Dan
>
> 2011/11/26 Zdenek Wagner :
>> 2011/11/25 Daniel Greenhoe :
>>> Hello Zdenek,
>>>
>>> 2011/11/25 Zdenek Wagner :
You can try zwpagelayout. ...
Versions 1.3 has just been released on CTAN, ...
>>>
>>> I am very interested in trying this. When I looked on ctan, it said
>>> that what was currently there was version 1.2. However the readme says
>>> version 1.3 with a date of 2011 November 22 and the pdf documentation
>>> also has a date of 2011 November 22 (but no version number). So I
>>> would guess that what is currently there is version 1.3, as you
>>> indicated.
>>>
>> It has been released just recently, maybe the catalogue is not yet
>> updated. The CTAN managers update the catalogue manually, thus it may
>> take some time.
>>
>>> Thank you!
>>> Dan
>>>
>>> 2011/11/25 Zdenek Wagner :
2011/11/25 Susan Dittmar :
> Hello Daniel,
>
> I had a glance at the current geometry documentation. Unfortunately, to
> me it
> looks like what you want is not implemented.
>
>> > Quoting Daniel Greenhoe (dgreen...@gmail.com):
>> >> Using the geometry package, is there any way to automatically (without
>> >> using layouthoffset and layoutvoffset) to center a layout area on a
>> >> physical page? The default seems for the layout to be pushed into the
>> >> upper left corner of the physical page. Here is an example:
>> >>
>> >> \documentclass{book}
>> >> \setlength{\parskip}{0mm}%
>> >> \setlength{\parindent}{0mm}%
>> >> \usepackage{geometry}
>> >> \geometry{
>> >> xetex,truedimen,paper=a4paper,
>> >> centering,twoside=false,
>> >> ignoreall,
>> >> layoutheight=200mm,layoutwidth=100mm,
>> >> margin=10mm,
>> >> nomarginpar,noheadfoot,
>> >> showframe,showcrop
>> >> }
>> >> \begin{document}%
>> >> abc
>> >> \end{document}%
>
> There seems to be no way of asking for a centered layout area on the
> physical page. Looks like you do have to set layouthoffset and
> layoutvoffset manually.
>
> Still my remark concerning having both "centering" and "margin=10mm" in
> the
> options list holds true. They affect the same internal values, one
> overwriting the other.
>
You can try zwpagelayout. I wrote it because geometry can do the
things that I do not need and cannot (or could not) do what I need
every day. Versions 1.3 has just been released on CTAN, it will soon
appear in TeX Live. The previous versions had problems with the
ifxetex package, thus it was necessary to load fontspec after
awpagelayout. The problem is fixed in 1.3.
> Hope that helps, at least a bit,
>
> Susan
>
>
> --
> Subscriptions, Archive, and List information,
Re: [XeTeX] VIQR pre-processor wrotten in (Xe)TeX ?
MY thanks to all who have offered helpful suggestions in VIQR. Unikey looks promising as an IME (I am waiting for my wife to tell me what the buttons say !), and a list member has kindly offered off-list to have a go at creating a TECkit map as and when he has time. So let us not expend further effort on this topic for the time being; it looks as if there are at least two fairly straightforward solutions. ** Phil. -- Subscriptions, Archive, and List information, etc.: http://tug.org/mailman/listinfo/xetex
[XeTeX] XETEX cannot access OpenType features in PUA?
Hello folks,
I'm working on an implementation of a font for Znamenny Neumatic
Notation in Unicode (see here:
http://en.wikipedia.org/wiki/Znamenny_chant)
Without getting too much into the details, I'll just state that the
notation includes base characters (neumes) and diacritics (red marks
or black marks). Sometimes, the neume may also change its shape, and
this is controlled via control characters in the proposed standard.
As the standard has yet to be proposed to Unicode, in the font the
glyphs are currently mapped to the Private Use Area. For the
implementation, the font makes heavy use of OpenType technology. In
particular, anchor points define the positions of red marks and black
marks over the neumes. The functions of control characters are handled
via a Ligature Substitution.
Now I'm writing up documentation for this standard in XeTeX.
But, it appears that XeTeX is unable to handle these features. For
example, consider this snippet:
\documentclass[12pt,a4paper]{article}
\usepackage{color}
\usepackage{xunicode}
\usepackage{xltxtra}
\usepackage{fontspec}
\defaultfontfeatures{Mapping=tex-text}
\newfontfamily{\moo}{MezenetsUnicode}
\begin{document}
{\moo \color{red}{}}
\end{document}
The control character is supposed to modify the neume (sort of
like a variation selector). Then, the diacritic is supposed to be
placed in accordance to the appropriate anchor point defined in the
font.
(None of these symbols will mean anything to you as you don't have the
MezenetsUnicode font that I've designed. You can download it here if
you wish to experiment: http://www.ponomar.net/files/mezen_uni.ttf
Please do not distribute this font -- it is only pre-beta software.)
Instead, I see the neume, a box for the control character, and
diacritic floating over nothing.
The font is OK, as the same characters in Pango and FIrefox produce
the desired results, so there is something wrong with the way XeTeX
handles GSUB and GPOS in the PUA. Is this a bug?
I'm running xelatex version 3.1415926-2.2-0.9995.2 on Ubuntu 11.10.
Thanks for any insights,
Aleks
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] Current Hebrew month spelled incorrectly in Polyglossia
It would be good to have the option to choose מרחשון, as that's what I
would normally write. Could we have a 'marcheshvan' option for
choosing this more traditional spelling?
Thanks,
Gareth.
On 23 November 2011 17:41, Joel C. Salomon wrote:
> On 11/23/2011 01:41 AM, Ari Meir Brodsky wrote:
>> The current Hebrew month is spelled incorrectly when using
>> \texthebrew{\today} in Polyglossia. It seems that the error is in line 58
>> of hebrewcal.sty, where the name השון should be changed to חשון.
>
> Is there an option to use the full name מרחשון?
>
> —Joel
>
>
> --
> Subscriptions, Archive, and List information, etc.:
> http://tug.org/mailman/listinfo/xetex
>
--
Gareth Hughes
garzoh...@gmail.com
public key ID: 0x9F32AF1E
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Re: [XeTeX] XETEX cannot access OpenType features in PUA?
Aleks,
I don't have a solution to your problem, but thought I'd write in to say
that I grabbed the font, opened it in FontForge and tested to make sure
the OpenType features seemed to be working correctly there (they were).
Then tried out your test file: saw the same problem you describe. I
don't know what the problem is, but I don't think it has to do with the
PUA or with putting a mark over an unencoded glyph: I've done that
plenty of times in my fonts, and have had no problem.
So this is just by way of saying that I can confirm the problem, but it
seems to me a real mystery.
Peter
On 11/25/2011 11:41 PM, Aleksandr Andreev wrote:
Hello folks,
I'm working on an implementation of a font for Znamenny Neumatic
Notation in Unicode (see here:
http://en.wikipedia.org/wiki/Znamenny_chant)
Without getting too much into the details, I'll just state that the
notation includes base characters (neumes) and diacritics (red marks
or black marks). Sometimes, the neume may also change its shape, and
this is controlled via control characters in the proposed standard.
As the standard has yet to be proposed to Unicode, in the font the
glyphs are currently mapped to the Private Use Area. For the
implementation, the font makes heavy use of OpenType technology. In
particular, anchor points define the positions of red marks and black
marks over the neumes. The functions of control characters are handled
via a Ligature Substitution.
Now I'm writing up documentation for this standard in XeTeX.
But, it appears that XeTeX is unable to handle these features. For
example, consider this snippet:
\documentclass[12pt,a4paper]{article}
\usepackage{color}
\usepackage{xunicode}
\usepackage{xltxtra}
\usepackage{fontspec}
\defaultfontfeatures{Mapping=tex-text}
\newfontfamily{\moo}{MezenetsUnicode}
\begin{document}
{\moo \color{red}{}}
\end{document}
The control character is supposed to modify the neume (sort of
like a variation selector). Then, the diacritic is supposed to be
placed in accordance to the appropriate anchor point defined in the
font.
(None of these symbols will mean anything to you as you don't have the
MezenetsUnicode font that I've designed. You can download it here if
you wish to experiment: http://www.ponomar.net/files/mezen_uni.ttf
Please do not distribute this font -- it is only pre-beta software.)
Instead, I see the neume, a box for the control character, and
diacritic floating over nothing.
The font is OK, as the same characters in Pango and FIrefox produce
the desired results, so there is something wrong with the way XeTeX
handles GSUB and GPOS in the PUA. Is this a bug?
I'm running xelatex version 3.1415926-2.2-0.9995.2 on Ubuntu 11.10.
Thanks for any insights,
Aleks
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
