On Mon, Apr 13, 2020 at 02:39:34PM +0530, RD Holkar wrote:
> thank you for the inputs. Now I feel that it is better to have a package
> for this purpose. The package is a better idea also as one may
> incorporate traditional marathi aspects of drama in it.
If you change your mind, I am happy to
Hello,
After some discussion we decided to put the subject line prefix back;
Karl just made the change and also set Mailman’s “munge from” option
(https://wiki.list.org/DOC/Mailman%202.1%20List%20Administrators%20Manual#line-163).
Best,
Arthur
On Wed, Dec 05, 2018 at 04:06:12PM +, John Was wrote:
> But the braces are
> certainly needed in *usage*: \overstrike{b}{p}
The braces are not needed in this example. Just try
\overstrike b p
or even
\overstrike bp
>
On Wed, Dec 05, 2018 at 02:47:26PM +, John Was wrote:
> Ah, another quirk of LaTeX.
Of TeX. As you can see in your own example:
> \def\overstrike#1#2{\setbox0=\hbox{#1}\setbox1=\hbox{#2}\copy0
>\kern -0.5\wd0 \kern -0.5\wd1 \copy1 \kern -0.5\wd1 \kern 0.5\wd0}
the arguments are
On Mon, Jul 30, 2018 at 09:25:19AM +0530, Shree Devi Kumar wrote:
> https://github.com/Shreeshrii/xetex-itrans/blob/master/wikner-skt-iast.map
> has a draft map based on the velthuis-devanagari map, but currently it does
> not support the initial Capitals (eg. AA needs to convert to Ā, "S to Ś).
Belated response:
On Wed, Sep 07, 2016 at 01:20:27PM -0400, Scott Kostyshak wrote:
> I run the following commands:
>
> git clone git://git.code.sf.net/p/xetex/code xetex-code &&
> cd xetex-code &&
> ./build.sh
>
> This gives the following error:
>
> /bin/bash:
>
> Second, about unicode, my experiences are mixed. I use Japanese as my main
> language of communication. I found that "plain XeLaTeX" is not really
> adequate for Japanese as it lacks many common features; LuaLaTeX performs
> better, but still not as good as the pre-UTF-8 special "Japanese
> https://sourceforge.net/p/xetex/bugs/134/
Great, thanks David.
Best,
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
> If you do find time to look at this... the other main issue besides \specials
> where the current model causes problems is the inability to specify direction
> while in vertical mode. The restriction to hmode was probably needed in
> tex-xet
> so the extra nodes got added at safe places but in
Hi Mike,
Many thanks to both of you for your hard work; sorry I couldn’t
contribute more; this week has been rather busy for me, with various
tasks, and a funeral to attend tomorrow.
Best,
Arthur
--
Hi Ross,
>> Unfortunately it's not really possible at the moment; the package pdfx
>> aims at producing different standards of the PDF/A and PDF/X families
>> but is aimed at pdfTeX. To my knowledge there has been no serious
>> effort to port it to XeTeX.
>
> There has now!
> I have
On Fri, Mar 18, 2016 at 12:07:26PM +, Philip Taylor wrote:
> You will, I am sure, be
> aware that I had not pursued the topic for some time
That's simply not true.
Arthur
--
Hi Mojca,
> Is there any better command than ./build.sh shortcut that I should be
> using? Can I somehow run separate steps for configure, make, test?
XeTeX’s build.sh only sets a number of variables and runs configure
and make, so if you’re scripting the process, it does indeed make
On Thu, Mar 17, 2016 at 11:58:34PM +, Philip Taylor wrote:
> The key point is this : only *TeX (where *TeX is any derivative
> of TeX; I do not wish to suggest modifying TeX itself out of respect for
> Don's wishes) /knows/ whether (e.g.,) an overfull \hbox has been
> generated during
> It may be that polyglossia is more careful about re-defining commands.
As I said, polyglossia isn't the package that defines that command,
neither is dialogue. It could be interesting to investigate in more
details but I really don't have the time right now. (And last time I
did that kind
On Thu, Feb 11, 2016 at 06:32:36PM +0100, Ulrike Fischer wrote:
> Am Thu, 11 Feb 2016 16:33:22 + schrieb Arthur Reutenauer:
>
> >> It may be that polyglossia is more careful about re-defining commands.
> >
> > As I said, polyglossia isn't the package that define
> Sure, just write
>
> \let\providelength\relax
>
> before the second package is loaded.
Or just load dialogue before polyglossia. For what it's worth, none
of these packages define \providelength themselves, they're defined in
packages they include.
Best,
On Mon, Feb 01, 2016 at 07:52:27PM -0700, Dominik Wujastyk wrote:
> I'm going to let this one go.
And no-one can blame you, Dominik :-)
Arthur
--
Subscriptions, Archive, and List information, etc.:
On Sun, Jan 31, 2016 at 05:33:49PM +, Jonathan Kew wrote:
> Arthur, if you have a chance to look at this and see if I missed anything
> obvious, that would be great - thanks.
No obvious issue for all I can say, apart for the comment change I
just pushed.
Best,
Hi Dominik,
On Fri, Jan 22, 2016 at 12:07:17PM -0700, Dominik Wujastyk wrote:
> I've just tried to provide the short examples, but I can't get the problem
> to manifest in a small sample yet. The student has a lot of included
> files, so it's non-trivial to whittle it down to the minimal
Hi Dominik,
> I left {CMU Serif Italic} as the document font, and added
> \XeTeXinputnormalization=1 to the preamble
>
> This also produced PDF that printed *correctly* in all cases. This is
> obviously the least fiddly solution.
I'm glad this worked for you, but like Zdeněk I’m a
> but perhaps an Adobe rendering engine might handle things better.
Yes, that's sound advice too. Whenever I've had problems with strange
font rendering, printing from Adobe Reader (or Acrobat Reader as it was
called earlier) very often helped.
Best,
Arthur
> I haven't encountered anything quite like this before, and it baffles me.
> I've tried outputting the PDF to PS and printing that. Printing the PDF to
> another PDF. I've tried using Evince not Okular. Always the same
> problem. Everything points to the printer or the printer driver.
Or a
Answering for Dominik, as that is easy to check by inspecting the PDF
file (the original one, obviously):
> I assume you have already considered: are the fonts embedded in the PDF?
Yes.
> Did he enter the characters as precomposed combinations or by using
> combining marks? First option
On Thu, Oct 08, 2015 at 01:01:37PM +0100, David Carlisle wrote:
> Here is a plain tex example, not quite as minimal as I'd like but out
> of time for now.
>
> This hyphenates with pdftex but not xetex
Many thanks David, that's really helpful.
Best,
Arthur
On Thu, Sep 10, 2015 at 02:02:13PM +0200, hanne...@staff.uni-marburg.de wrote:
> In the first case, writing Sanskrit in transliteration, one would write
> typically within an English, other Euopean,
> or Japanese (or whatever) environment that constitutes the main language.
> One just uses a few
On Thu, Sep 03, 2015 at 10:44:19AM -0400, Adam Drissel wrote:
> I need to be able to use XeTeX while still producing a PDF in x1a format
> (PDF/A, PDF-x1a). Do you have any idea how I can do this using XeTeX?
Unfortunately it's not really possible at the moment; the package pdfx
aims at
On Fri, May 22, 2015 at 04:49:58PM -0400, Stephen Moye wrote:
Atta boy! You tell 'em! Take THAT!
Was that really meant for the list?
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Also, the original version of xetex was developed by SIL (SIL
also has some useful fonts), and SIL works with such minority languages
exclusively. So while it may be possible for the *tex engine or fonts to
omit the dotted circle, it doesn't seem to be a very high priority.
While working on these bugs, we also discussed how surrogate
characters were handled in XeTeX. Surrogate characters are the 2048
code points that are used in UTF-16 to encode characters with code
points above 65536: a pair of them makes up one Unicode character;
however they're not meant to be
I do realize the usual MWE requirement, and I did not provide one at first
because really what I was trying to find out was not related to a specific
example, but more the matter of whether Luabidi was likely to be upgraded
so as to be as fully functional as XeTeX bidi, as Vafa had suggested
Dear Karljürgen,
I am glad that you were able to find a solution to your problem with
the help of David. I did note your plea for help (already back in
October), and of course your private email to me two days ago, but while
I spent many hours trying to figure out what you were trying
Obviously the non-BMP issue needs to be tackled, but I wonder if \Uchar
could be added in any case. It would bring functionality in this area
closer to LuaTeX and presumably the high chars business can be viewed as
a separate issue.
I tend to agree. There must be an issue with
I do not understand. If system A performed function Y until now, yet
its designer/maintainer wishes it to perform function Y' henceforth
Khaled's point is that XeTeX did not work correctly on the issue at
hand until he made the change we're discussing. It's unfair to
characterise his change
In that case (and this is partially off-topic), what is the correct
mechanism by which one should instruct XeTeX (current version : TL-2014)
to reverse that stretch of text ?
\beginR, \endR, it's in the subject of this thread.
I have a 544pp book that
Fair enough. My thought was simply that if a sufficiently large number
of users are dependent (even tacitly) on the current behaviour, then
opting-in to the new should not be out of the question ...
That's the eternal question, isn't it - to which extend should a buggy
behaviour be
Hi Sasi,
Although I had written about this problem earlier and got some responses
Did you read them?
am
giving a minimal working example below. It gives a pdf that has rectangles
where I have placed quotes and
Have you tried using a non-breaking space (U+00A0) as the base letter?
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
The problem is that AFAIK the Indic scripts are not yet implemented in
luatex.
Actually it is, at least for Devanagari. This is fairly recent (2-3
years).
The dotted ring is not a part of the glyph. the Unicode shaper
(HarfBuzz in XeTeX) knows that visarga is a dependent vowel
And why does Jonathan's example
use the reformed orthopgraphy patterns when we are trying
to hyphenate words with eszet ?
It works with the 1901 patterns too.
Arthur
--
Subscriptions, Archive, and List
Well, LUATEX uses a finite state hash to match the patterns against the
word to be hyphenated., so it would seem to me that LuaTeX's behaviour
cannot be considered as normative.
If indeed LuaTeX finds hyphenation points that XeTeX misses, using the
same patterns, it is an improvement. But I
Amazing! When a feature was ignored, it had the desirable effect, and
caused frustration when properly taken into account.
It's not that uncommon, actually. But still amazing when you realise
it happened.
Now I'd like to know how Akira figured out you needed to set -ccmp
too :-)
The fontspec manual describes it. The keywords are rlig, hlig, clig, etc.
For more details on OpenType tags, you might want to check the
specification, and match the list of tags defined in the font at hand
with it: http://www.microsoft.com/typography/otspec/featuretags.htm
Also, the
Thank you. This is just what I needed. Incidentally, the tag +liga
yielding ligatures for fi, ff, fl, ffi and ffl is the default.
It shoul be disabled for small caps:
I'm pretty sure this is taken care of by the font. Have you observed
a small caps fi ligature? I don't even see why a font
Hello,
I can confirm that with TeX Live 2013 pretest. The problem is that
xwatermark needs hyperref but postpones it inclusion until the end of
the preamble, and that bidi wants to be loaded last, as you can see from
the error message. Hence both packages fight to be included last.
Hi Arthur, I have already tested that but what happen is the output
document is empty.
Oh right, I see that now. You mean only the first page, the one that
contains the watermark? I hadn't notice before.
Arthur
--
Subscriptions,
Yes, I meant in your example. Since the problem is in the interaction
between xwatermark and bidi, I'm not surprised that the pages that fail
are the ones with watermarks on them.
I have no solution for that, and don't really have the time to look
into it, sorry. If what you want is to add
Well, it works OK on my computer, but note that the DRAFT shows up in a
rather strange place...
Well, that's progress ;-) What version of all these packages are you
using?
Arthur
--
Subscriptions, Archive, and List information,
Thanks. The difference seems to be in the bidi version. I have been
using version 13.5 dated 2013/05/28, from TeX Live 2013 pretest, while
you (Wilfred) are using version 12.2 dated 2013/04/04 -- presumably from
the frozen TeX Live 2012. I can actually reproduce the behaviour you're
observing
File associations is unlikely to be your problem here: as the message
says, xdvipdfmx can't be found. It may be a path problem, or worse; is
the xdvipdfmx program at least still present on your system? It should
be in the same directory as XeTeX.
Arthur
A separate
question: I wasn't aware that an OpenType font even knew anything about
official Unicode code point names, so how does FontBook know which glyphs
have Unicode names and which ones don't??
There is nothing in OpenType about
It is strange because I am unable to find a package named etoolbox in ctan.
Wilfred has already given the link to the package on CTAN, and as he
said it is part of TeX Live; in the collection latexextra, to be
precise. What's strange is how you managed to install polyglossia
without
I would like to ask you for help with longtable and right to left writing
direction, please. As the attached example with polyglossia, longtable
You haven't attached anything, it seems; at least I can't see an
attachment.
Arthur
--
I am really sorry, I forgot to attach the files! Here they are:
And I'm sorry too, because I didn't notice your second message ;-)
Next time, if you could reply to yourself, that would make it easier to
follow the thread.
Anyway, your problem is addressed at section 3.1 of the
Good thing that you anticipated it ;-)
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
On Sat, Mar 30, 2013 at 10:18:49PM +0100, Peter Dyballa wrote:
Exactly. But when Malayalam uses as punctuation or in calendar dates Latin
script characters, why is Polyglossia using a Malayalam font to display these
entities?
Because you told it to. You set up Malayalam to be the main
What's more, there have been numerous reports that mismatches between
the font file XeTeX finds, and the one the PDF driver finds, caused
problems. I can even remember someone stating on this list, a few years
ago, that he wrote a script to hardcode font file paths in the XDV files
XeTeX
I can not reproduce the problem either, but evidently your problem is
with the program that produces PDF from XDV (either xdvipdfmx or
xdv2pdf), not with XeTeX itself. That's what the last two lines you're
quoting mean. It would really help if you could tell us what version of
these programs
On Wed, Dec 12, 2012 at 04:42:39PM +0100, François Patte wrote:
While looking on this page http://tug.org/tex-hyphen/, I have seen that
left-right-hyphenmin for sanskrit are set to (1,5). Why 5?
That value for \righthyphenmin has been provided early on in the
development of the hyphenation
On Mon, Dec 03, 2012 at 09:50:12AM +0100, Lorenz Haas wrote:
as the error message says: something is wrong with the setmainfont
statement.
No, that's not what the error message says, it says that \setmainfont
doesn't exist at all. That's because Polyglossia has not been loaded.
It is fixed
On Mon, Dec 03, 2012 at 09:42:34AM +, Arthur Reutenauer wrote:
No, that's not what the error message says, it says that \setmainfont
doesn't exist at all. That's because Polyglossia has not been loaded.
And I of course meant fontspec. Oops ;-)
The three lines should thus read
On Mon, Dec 03, 2012 at 05:02:39PM +0530, Sasi Kumar wrote:
! Undefined control sequence.
l.26 \ocp
\malA=mal-uni01
That looks like something inherited from Omega. Please include the
full log file, or at least several lines in the part immediately
preceding that error message. The
On Mon, Dec 03, 2012 at 07:34:52AM -0600, Herbert Schulz wrote:
You need to use the fontenc package. Also, if you are going to use otf fonts
there is no need for the fontenc package.
Herbert of course meant to write fontspec in his first sentence ;-)
Arthur
On Wed, Sep 12, 2012 at 03:34:19PM -0400, Joel C. Salomon wrote:
About a month ago Arthur Reutenauer posted to this list (and some
others) that experimental support for LuaTeX had been added in the
development version he maintains at
http://github.com/reutenauer/polyglossia.
The support
Royal Albert Hall, London, 6 August 2012
I have the pleasure to announce version 1.30MM of Polyglossia, that
comes with experimental support for LuaTeX. Unfortunately I can't make
an upload to CTAN at the moment because the two CTAN'ers are on holidays
(can't blame them), but brave users can
Ha, I was wondering how long it would take for someone to notice :-)
I just started porting Polyglossia to LuaTeX. I didn't have time to
do much yet, but I expect it's going to be a matter of days till all the
gloss files work. For the moment, all the languages relying on XeTeX's
Whenever anything is available for testing, I can try some Czech and
Slovak texts.
Thanks. I will let you know when it's ready to be tested.
Arabic should work fine, but I'm not even sure about Syriac, for
example.
How about Urdu? It will be difficult for me but I can try to run some
My wondering was more whether what ConTeXt implements was actually
enough for Urdu (and other languages). As far as I know Oriental TeX is
only concerned with Arabic texts. But it's entirely possible that Urdu
would just work out of the box with ConTeXt / luaotfload's shaping
engine.
I remember specifically testing some Nastaliq fonts and Hans fixing some
small issues I found, I just tested again now and IranNastaliq seems to
work
OK cool, good to know.
Arthur
--
Subscriptions, Archive, and List information,
It says everywhere that luatex supports UTF-8, yet my (very
limited) understanding is that Unicode string support in *lua*
is entirely dependent on third party additions.
LuaTeX includes such a third-party addition for UTF-8 string
processing, called Selene
Javier, that's great news! I suppose you're part of the team
developing it?
Glad to see the ball gets rolling again for Babel.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
Hello,
On Sat, Nov 26, 2011 at 03:41:31PM +, Gareth Hughes wrote:
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?
In a long overdue action item, I
I don’t know the technical answer to that question, but considering
what you say:
I would have expected the translittered text to be
hyphenated according the original russian rules but actually it is
not hyphenated at all:
That hints that the text is hyphenated after
It should be so.
I agree with that, that’s the most sensible behaviour. What Ulrike
needs are hyphenation patterns suited to the particular transliteration
scheme she’s using. Depending on the transliteration, the patterns for
other Slavonic languages could be useful; for ISO 9, I expect
Hi Adam,
In order to use the Georgian script, all you need is an appropriate
font, and fontspec to load it, with commands such as
\setmainfont[Script=Georgian]{font name}
or \setotherfont if your main document script isn't Georgian.
There is no Georgian support in Babel.
On Fri, Nov 18, 2011 at 10:16:31AM +0100, Keith J. Schultz wrote in
reply to Ross Moore:
You are probably a little young to know this, but TeX's original output
format was a dvi file.
I think I'll have this one framed and sent to Ross for his next
birthday.
Arthur
On Tue, Nov 15, 2011 at 02:20:17PM +, Philip TAYLOR wrote:
No ! A catcode is for life, not just for Christmas ! Once a
character has been read, and bound into a character/catcode pair,
that catcode remains immutable.
Do you mean that as a general good practice in TeX programming, or as
The latter is what the TeXbok says (P.~39) : Once a category code
has been attached to a character token, the attachment is permanent.
Yes, because you meant individual tokens (which I understood in
retrospect). But in the context of the discussion, you really seemed to
be saying that you
Thanks, it confirms what I suspected (I tried to compile your TeX file
but didn't get the same result; the xepersian version was too old on the
computer I was using then, I guess). XeTeX really seems to take bytes
in account when printing messages to the log file and terminal; not
characters.
Off the top of my head, it could be that XeTeX truncates its output to
79 bytes (not characters), and that some of the UTF-8 byte sequences are
(incorrectly) split in half. The two codes you see on either side of
the line (DB and B1), when interpreted as hexadecimal digits, are the
UTF-8 form
Just edit your language.def file. Actually, you can create a one-line
file that says british loadhyph-en-gb.tex (not hyph-en-gb.tex!) and
create the format with fmtutil.
Arthur
--
Subscriptions, Archive, and List information, etc.:
BOM is already used in outlines but the application that creates PDF
has to write BOM. As Arthur wrote, there are a lot of files in UTF-8
that do not have BOM. Even in XML BOM is only optional.
Actually, it even used to be frowned upon in UTF-8 text :-) It was
originally meant for tagging
Phil,
Please stop. I am serious. Just stop.
Arthur
--
Subscriptions, Archive, and List information, etc.:
http://tug.org/mailman/listinfo/xetex
I do not think, it makes any difference.
-jobname=STRING set the job name to STRING
-progname=STRINGset program (and fmt) name to STRING
-jobname doesn't make any difference because it's set from the base
name of the first input (in that case, xelatex.ini), but -progname
On Sat, Oct 15, 2011 at 02:23:29PM -0500, Neal Delmonico wrote:
One thing still
bothers me about that whole affair. I am working on several books
involving Sanskrit and English and requiring hyphenation in both.
None of the other books had
On Tue, Oct 18, 2011 at 05:49:28AM +0800, Daniel Greenhoe wrote:
Does anyone know of any data base
with a traditional to simplified character mapping such that I could
maybe write the utility myself?
Unicode has that in the Unihan database: look up
Hm. I don't understand how this can be a general usable work-around.
What actually is the appropriate directory here? Do you have a
newer/local version of latex.ltx in this directory?
Actually, if you look at a latex.ltx that has that check (the one from
stock TeX Live 2011 still has code
Hello,
I uploaded a new version of Polyglossia to CTAN (version 1.2.0cc), and
it should appear in distributions shortly. This fixes a number of
outstanding bugs, thanks mostly to Enrico Gregorio who contributed a lot
of code to the Github repository in the past year -- but these
On Fri, Oct 07, 2011 at 10:43:41PM +0530, Dominik Wujastyk wrote:
The new polyglossia in TeXlive 2011 just updated from CTAN, to version
1.2.0b. Thanks everyone!!!
Note that this only adds xkeyval to polyglossia; it does not change
anything else and does in particular not correct the odd
Hi all,
On Tue, Oct 04, 2011 at 09:05:10PM +0200, FC wrote:
I will also forward to him all emails I have received relating to
polyglossia during the past year.
I'm still waiting, by the way ;-)
Obviously this new situation will be for the common benefit of all XeTeX
users. I
Thanks. I will try this and uncomment the \setotherlanguage{Sanskrit}. That
way if there are any hyphenations in the Hindi verse, they will occur
correctly. Am I correct in thinking this?
You've got it mostly right. I was going to write a detailed and
intricate answer, but it's
I have been through the introduction and first
chapter correcting the mistaken hyphenations by hand.
Please don't do that, it is a total waste of your own time. There is
a bug in Polyglossia. It needs to be fixed, but for the time being it's
enough if you add
So something is wrong with
polyglossia, from which I suppose the command comes from.
Yes, that must be the problem. Last time I checked, Polyglossia used
\AtBeginDocument to set \lefthyphenmin and \righthyphenmin, and a
side-effect of that may be that the
On Wed, Aug 31, 2011 at 07:52:43PM +0200, Peter Dyballa wrote:
Am 31.08.2011 um 16:50 schrieb Jonathan Kew:
Why, is there a problem with running the current (Intel build of) xetex on
10.7? I wasn't aware of this.
And neither me. Because I'm not using Lion (Mac OS X 10.7).
Seems like
A supplementary question : how does the PDF appear when
viewed in Acrobat Reader or in Adobe Acrobat ? From a
purely personal perspective, I would always check the
rendering in those before assuming that the PDF was at
fault -- it may well be simply an incompatibility with
the viewer(s).
Then why is Unicode proposing / imposing it that way?
Unicode has nothing with it; OpenType is the font standard. And as to
why it proposes / imposes / disposes it that way, it's hard to say,
because it's simply ill-advised to use font substitutions for what
you're looking for. You want the
Pinyin patterns already exist in our repository, so one should be able
to use them out-of-the-box, while for the rest we don't have anything
yet.
I have patterns that work for Japanese, I'll send an e-mail about it
later; first I have something else to finish ;-)
Arthur
Can someone please explain why is it that if I compile the document:
\documentclass{article}
\usepackage{fontspec,lmodern}
\usepackage[T1]{fontenc}
\begin{document}
«A»
\end{document}
what I get is
ńAż
instead of
«A» ?
Because you're using fontenc. Don't. Just let
Hmm, looking at Microsoft's recommendations[1], it sounds like you should be
aiming for glyph 1, and character codes that should map to that glyph include
U+ (null), U+0008 (backspace) and U+001D (group separator).
Thanks Jonathan, that's most useful. Sadly, all of these characters
And another nasty issue (that might deserve its own thread). We wanted
to have no hyphenchar at all, but using \hyphenchar\font=0 has a nasty
consequence that lines with broken words are not properly justified
(some extra space is squeezed between the last character in line and
the
1 - 100 of 136 matches
Mail list logo
