headers
Ralf Stubner | 1 Sep 2005 09:26
Picon

Bug#325891: tetex-doc: should not include xcolor documentation

Frank Küster wrote:
> Ralf Stubner <ralf.stubner <at> web.de> wrote:
>
>> tetex-doc should not include the xcolor documentation, which is provided
>> by the latex-xcolor package. 
> 
> Fixed in svn.

Thanks.

>> pgf's bug #301848 also applies to latex-xcolor and latex-beamer.
> 
> Have you submitted bugs against latex-beamer and -xcolor?

No. Since all three packages are maintained by the same person, I
thought it is enough to send an appropriate comment to #301848, also
mentioning this bug here. I hope that is enough.

cheerio
ralf

--

-- 
To UNSUBSCRIBE, email to debian-tetex-maint-REQUEST <at> lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster <at> lists.debian.org
Permalink | Reply | 0 comments |
headers
Debian Bug Tracking System | 1 Sep 2005 09:33
Picon

Processed: reopen 316245

Processing commands for control <at> bugs.debian.org:

> reopen 316245
Bug#316245: tetex-bin: postinst failure while building etex and pdfetex formats
Bug reopened, originator not changed.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)
Permalink | Reply | 0 comments |
headers
Frank Küster | 1 Sep 2005 11:11
Picon

Bug#322713: (fwd) Bug#322713: dvipdfm doesn't understand gs anymore

Ralf Stubner <ralf.stubner <at> web.de> wrote:

>> For more than 3 years, DVIPDFMx have been extensively tested by many
>> users. There might be some bugs which are not found yet. But the authors
>> of DVIPDFMx try to fix immediately if reported to them.
>
> Sounds good. Maybe we should contact Thomas Esser and suggest switching
> to dvipdfmx?

the texlive list seems the best place for this decision, since teTeX and
texlive usually follow each other closely, and Thomas also reads there.

Regards, Frank
--

-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Permalink | Reply | 0 comments |
headers
Frank Küster | 1 Sep 2005 11:23
Picon
Favicon

Re: luximono: problems and success

Joerg Sommer <joerg <at> alea.gnuu.de> wrote:

> Hello Frank,
>
> Frank Küster <frank <at> debian.org> wrote:
>> Joerg Sommer <joerg <at> alea.gnuu.de> wrote:
>>
>>> Hi,
>>>
>>> some time ago I expressed the wish to install fonts in my home dir and
>>> not lose the system fonts. This was implemented in the new tetex 3
>>> packages and today I tested it.
>>
>> Very good to get practical experiences.  Which version of the packages
>> did you use?
>
> Oh sorry, I missed out them:
>
> $ dpkg -l tete* |grep ^ii
> ii  tetex-base     3.0-6          Basic library files of teTeX
> ii  tetex-bin      3.0-5          The teTeX binary files
> ii  tetex-doc      3.0-3          The documentation component of the Debian te
> ii  tetex-extra    3.0-6          Additional library files of teTeX

And tex-common?

>>> After all this, I called updmap
>>
>> Probably you also called update-updmap, right?
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vladimir Volovich | 1 Sep 2005 19:51
Picon

Bug#250216: [tex-k] Plans about supporting TrueType/Type42 fonts in dvips?

"PV" == Paul Vojta writes:

 PV> I have looked into supporting TrueType in xdvi.  A key subsidiary
 PV> issue that came up (and stopped it for me) was compatibility with
 PV> ttf2tfm and ttf2pk.  They come up with their own character
 PV> encoding that basically (as I recall) chooses the lowest-numbered
 PV> 255 or 256 available characters into the encoding vector.  Adding
 PV> to the difficulties is the fact that ttf2tfm/ttf2pk use the old
 PV> (version 1) freetype library.  I tried porting these programs to
 PV> freetype2, but the latter lacks some features of the original
 PV> freetype, and is never likely to have them (Werner Lemberg said
 PV> that programs should use pango instead for these features).

above you wrote "I have looked into supporting TrueType in xdvi",
which as far as i understand shall mean ability to render (using
freetype library) glyphs directly from TrueType fonts, and of course
also selecting the needed glyphs of the TrueType fonts according to
the ReEncodeFont instructions from the MAP files.

yet, later you write about ttf2tfm and ttf2pk and how they are using
old freetype library etc.

i do not see any relation between "support of TrueType in xdvi" and
those two programs - ttf2tfm and ttf2pk. there is no relation
whatsoever. ttf2tfm is one of the many ways to create TFM metrics from
the TrueType fonts, and ttf2pk is, as you know, just a converter from
TrueType to PK for those programs which DO NOT support TrueType, and
thus need to fall back to use PK fonts.

could you please explain what do you mean?
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Vojta | 1 Sep 2005 20:47
Picon
Favicon

Bug#250216: [tex-k] Plans about supporting TrueType/Type42 fonts in dvips?

On Thu, Sep 01, 2005 at 09:51:51PM +0400, Vladimir Volovich wrote:
> "PV" == Paul Vojta writes:
> 
>  PV> I have looked into supporting TrueType in xdvi.  A key subsidiary
>  PV> issue that came up (and stopped it for me) was compatibility with
>  PV> ttf2tfm and ttf2pk.  They come up with their own character
>  PV> encoding that basically (as I recall) chooses the lowest-numbered
>  PV> 255 or 256 available characters into the encoding vector.  Adding
>  PV> to the difficulties is the fact that ttf2tfm/ttf2pk use the old
>  PV> (version 1) freetype library.  I tried porting these programs to
>  PV> freetype2, but the latter lacks some features of the original
>  PV> freetype, and is never likely to have them (Werner Lemberg said
>  PV> that programs should use pango instead for these features).
> 
> above you wrote "I have looked into supporting TrueType in xdvi",
> which as far as i understand shall mean ability to render (using
> freetype library) glyphs directly from TrueType fonts,

Correct (so far)

> and of course
> also selecting the needed glyphs of the TrueType fonts according to
> the ReEncodeFont instructions from the MAP files.

AFAIK there is only one .map file, ttfonts.map, which plays a role similar
to that played by psfonts.map used by dvips.

> yet, later you write about ttf2tfm and ttf2pk and how they are using
> old freetype library etc.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hilmar Preusse | 1 Sep 2005 21:33
X-Face
Picon

Re: libkpathsea transition

On 30.08.05 Frank Küster (frank <at> debian.org) wrote:
> Hilmar Preusse <hille42 <at> web.de> wrote:

Hi all,

> > Hmm, wasn't it the case, that the old libkpathsea3 implements the
> > new TDS, while libkpathsea4 understands the new one? I.e. a
> > program linked with libkpathsea3 won't work with tetex 3.0? Or am
> > I totally broken?
> 
> Actually the TDS changes are mainly in texmf.cnf - there might be
> some new variables that only the new kpathsea understands.
> 
Hmm, OK.

> I think that a program linked against libkpathsea3 (and using this
> version, of course) would still find most files on a putative unstable
> system with teTeX-3.0. If it doesn't, that would be inconvenient for
> the unstable user
> 
I'd like to have it tested before simply assuming that the search lib
does not affect anything. E.g. the japanese version of dvips would
search map files etc. at the wrong place, which would completely
break the package.
But this is all IMHO. I've no clue how all this internally works.

> However, if we just upload teTeX-3.0 into unstable, libkpathsea3
> would vanish, and all packages that get recompiled after that are
> linked against libkpathsea4.  Then they could not enter testing
> before tetex-bin and libkpathsea4 enters testing.  And this would
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vladimir Volovich | 1 Sep 2005 22:51
Picon

Bug#250216: [tex-k] Plans about supporting TrueType/Type42 fonts in dvips?

"PV" == Paul Vojta writes:

 >> above you wrote "I have looked into supporting TrueType in xdvi",
 >> which as far as i understand shall mean ability to render (using
 >> freetype library) glyphs directly from TrueType fonts,

 PV> Correct (so far)

 >> and of course also selecting the needed glyphs of the TrueType
 >> fonts according to the ReEncodeFont instructions from the MAP
 >> files.

 PV> AFAIK there is only one .map file, ttfonts.map, which plays a
 PV> role similar to that played by psfonts.map used by dvips.

hey, forget about ttf2pk and it's ttfonts.map. :-)

e.g. pdftex natively supports TrueType fonts and it doesn't care what
ttf2pk has in it's ttfonts.map (and this map is only needed for
re-mapping the glyphs in the TrueType fonts, and not for rendering).

pdftex just understands the same syntax for re-mapping the TrueType
fonts as for Type 1 fonts (via ReEncodeFont), and also understands
other dvips-like syntax like ExtendFont, SlantFont, etc.

so does xdvi with it's ps2pk.map: why re-invent the wheel and care
about syntax of ttfonts.map? just continue to use your ps2pk.map's
syntax for truetype fonts as well.

 >> yet, later you write about ttf2tfm and ttf2pk and how they are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joerg Sommer | 1 Sep 2005 22:53
Picon

Re: luximono: problems and success

Hello Frank,

Frank Küster <frank <at> debian.org> wrote:
> Joerg Sommer <joerg <at> alea.gnuu.de> wrote:
>
>> Frank Küster <frank <at> debian.org> wrote:
>>> Joerg Sommer <joerg <at> alea.gnuu.de> wrote:
>>>
>
> And tex-common?

ii  tex-common     0.5            Common infrastructure for using and building

>>> Again the question about package versions, this time more detailed: At
>>> which version did you read the manpage of updmap(-sys) and other
>>> documentation?
>>
>> Never.
>>
>>> It changed a bit recently, so I'm wondering whether the new text would
>>> have informed you better, or still needs to be rephrased or extended.
>>
>> I read the mail from Florent Rougon (<87k6ksd9dj.fsf <at> florent.maison> or
>> <news:4gvtQ-x4-7 <at> gated-at.bofh.it>) on this list.
>
> Ah, well, then at least we can't blame our documentation.  I'm not sure
> what's in this message, but even if it is still correct, it probably
> assumes some prior knowledge that you didn't have.

Where is the offical documentation for adding fonts to user home dirs?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Frank Küster | 2 Sep 2005 08:55
Picon
Favicon

Re: libkpathsea transition

Hilmar Preusse <hille42 <at> web.de> wrote:

> On 30.08.05 Frank Küster (frank <at> debian.org) wrote:
>> Hilmar Preusse <hille42 <at> web.de> wrote:
>
> Hi all,
>
>> > Hmm, wasn't it the case, that the old libkpathsea3 implements the
>> > new TDS, while libkpathsea4 understands the new one? I.e. a
>> > program linked with libkpathsea3 won't work with tetex 3.0? Or am
>> > I totally broken?
>> 
>> Actually the TDS changes are mainly in texmf.cnf - there might be
>> some new variables that only the new kpathsea understands.
>> 
> Hmm, OK.
>
>> I think that a program linked against libkpathsea3 (and using this
>> version, of course) would still find most files on a putative unstable
>> system with teTeX-3.0. If it doesn't, that would be inconvenient for
>> the unstable user
>> 
> I'd like to have it tested before simply assuming that the search lib
> does not affect anything. E.g. the japanese version of dvips would
> search map files etc. at the wrong place, which would completely
> break the package.

Testing before uploading is always a good idea.  On the other hand, we
can't test every package that interacts with TeX, and must put some load
on the maintainers.  I think I'm going to write a mail to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane