textrace-main Mailing List for TeXtrace
Brought to you by:
pts
Menu
▾
▴
textrace-main — TeXtrace news, bugs, feature requests, testimonials etc.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(32) |
Aug
(11) |
Sep
(4) |
Oct
(4) |
Nov
(11) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(1) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Emanuele V. <ema...@ho...> - 2002-08-30 01:50:17
|
Greetings,
The problem seems to be related to a missing gs device: bbox. The change
list for 7.05 says:
Create the bboxutil pseudo-device to allow inclusion of the bbox
device for internal use by those drivers that require it without
putting it on the list of devices.
Saluti,
Emanuele.
_________________________________________________________________
Specisci e ricevi le tue email Hotmail dal tuo cellulare con:
http://mobile.msn.it
|
|
From: Andrey V. P. <pa...@ia...> - 2002-07-16 16:02:58
|
12 Июль 2002 22:05, Вы написали:
> > It seems that textrace (as of version 0.49) does not work with GNU gs
> > 7.05, at least Slackware 8.1 binary.
>
> Can you send me a more specific bug report (see the docs about sending
> bug reports)? I don't have neither Slackware 8.1, nor gs 7.05.
>
The output of traceall script:
$ traceall.sh ecti0900 ecti0900.pfb 4321012
> tex \setbox0=\hbox{\vrule height 10pt width 10pt}\shipout\box0\end
This is TeX, Version 3.14159 (Web2C 7.3.1)
[1]
Output written on texput.dvi (1 page, 140 bytes).
Transcript written on texput.log.
> dvips tmp/texput.dvi -o tmp/texput.ps
This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com)
' TeX output 2002.07.17:0956' -> tmp/texput.ps
<texc.pro>. [1]
DPI: 600
requested ptSize: ecti0900 at 120.45 pt
1000/ptSize: 8.302200083022
> tex \newdimen\ptsize\ptsize=120.45pt \def\whatfont{ecti0900 at
120.45pt}\def\P
utBox{\kern-\ht1\box1}\def\whatmul{8.302200083022}\input tmpdump
This is TeX, Version 3.14159 (Web2C 7.3.1)
\ptsize=\dimen16
(tmpdump.tex [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]
[15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29]
[30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44]
[45] [46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59]
[60] [61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74]
[75] [76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89]
[90] [91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103]
[104] [105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115]
[116] [117] [118] [119] [120] [121] [122] [123] [124] [125] [126] [127]
[128] [129] [130] [131] [132] [133] [134] [135] [136] [137] [138] [139]
[140] [141] [142] [143] [144] [145] [146] [147] [148] [149] [150] [151]
[152] [153] [154] [155] [156] [157] [158] [159] [160] [161] [162] [163]
[164] [165] [166] [167] [168] [169] [170] [171] [172] [173] [174] [175]
[176] [177] [178] [179] [180] [181] [182] [183] [184] [185] [186] [187]
[188] [189] [190] [191] [192] [193] [194] [195] [196] [197] [198] [199]
[200] [201] [202] [203] [204] [205] [206] [207] [208] [209] [210] [211]
[212] [213] [214] [215] [216] [217] [218] [219] [220] [221] [222] [223]
[224] [225] [226] [227] [228] [229] [230] [231] [232] [233] [234] [235]
[236] [237] [238] [239] [240] [241] [242] [243] [244] [245] [246] [247]
[248] [249] [250] [251] [252] [253] [254] [255] [256] )
Output written on tmpdump.dvi (256 pages, 15108 bytes).
Transcript written on tmpdump.log.
> dvips -t Asis tmpdump.dvi -o tmpdump.ps
This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com)
' TeX output 2002.07.17:0956' -> tmpdump.ps
<texc.pro>. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]
[16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30]
[31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] [45]
[46] [47] [48] [49] [50] [51] [52] [53] [54] [55] [56] [57] [58] [59] [60]
[61] [62] [63] [64] [65] [66] [67] [68] [69] [70] [71] [72] [73] [74] [75]
[76] [77] [78] [79] [80] [81] [82] [83] [84] [85] [86] [87] [88] [89] [90]
[91] [92] [93] [94] [95] [96] [97] [98] [99] [100] [101] [102] [103] [104]
[105] [106] [107] [108] [109] [110] [111] [112] [113] [114] [115] [116] [117]
[118] [119] [120] [121] [122] [123] [124] [125] [126] [127] [128] [129] [130]
[131] [132] [133] [134] [135] [136] [137] [138] [139] [140] [141] [142] [143]
[144] [145] [146] [147] [148] [149] [150] [151] [152] [153] [154] [155] [156]
[157] [158] [159] [160] [161] [162] [163] [164] [165] [166] [167] [168] [169]
[170] [171] [172] [173] [174] [175] [176] [177] [178] [179] [180] [181] [182]
[183] [184] [185] [186] [187] [188] [189] [190] [191] [192] [193] [194] [195]
[196] [197] [198] [199] [200] [201] [202] [203] [204] [205] [206] [207] [208]
[209] [210] [211] [212] [213] [214] [215] [216] [217] [218] [219] [220] [221]
[222] [223] [224] [225] [226] [227] [228] [229] [230] [231] [232] [233] [234]
[235] [236] [237] [238] [239] [240] [241] [242] [243] [244] [245] [246] [247]
[248] [249] [250] [251] [252] [253] [254] [255] [256]
> gs -sDEVICE=nullpage -q -dNOPAUSE -dtO0P={/bbox finddevice setdevice
2 dict dup begin /.HWMargins [-3000 -3000 0 0] def /PageSize [4000 4000]
de
f end setpagedevice
showpage} -dbO0P={bop} -deO0P={eop} tmp/tmpdump2.ps -c quit
> gs -sDEVICE=nullpage -q -dNOPAUSE -dtO0P={(pbmsave.ps)run /wwhs 256 array
def
/endwwhs{mark 5 1 roll counttomark array astore exch pop put}bind def
(tmp/tmpdump2.bbx)run } -dbO0P={2 copy bop pop 255 and wwhs exch get
aload
pop
% stack: w h sx sy
4 copy pop pop
_makeULPBMdevice setdevice
neg translate
600 exch 600 add translate
pop
} -deO0P={currentdevice _printPBMbinary
eop} tmp/gstderr.ps tmp/tmpdump2.ps -c quit
rleman: building tmp/tmp_chrs.rea
Fatal error: error running gs: /typecheck in --.unread-- at 1246600.
0 sub-files
Fatal error: error running gs
7$ cat tmp/gstderr.ps
/handleerror {
(tmp/tmp_gs.err) (w) file
dup (!!!Fatal: GS error: ) writestring
dup $error /errorname get write==only
dup ( in ) writestring
dup $error /command get write==only
dup ( at ) writestring
dup $error /position get write==only
dup (.\n) writestring
flushfile flush quit
}bind def
Ghostscript version:
$ gs -h
GNU Ghostscript 7.05 (2002-04-22)
Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved.
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
-dNOPAUSE no pause after page | -q `quiet', fewer messages
-g<width>x<height> page size in pixels | -r<res> pixels/inch resolution
-sDEVICE=<devname> select device | -dBATCH exit after last file
-sOutputFile=<file> select output file: - for stdout, |command for pipe,
embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PDF
Available devices:
x11 x11alpha x11cmyk x11gray2 x11gray4 x11mono bmpmono bmpgray bmpsep1
bmpsep8 bmp16 bmp256 bmp16m bmp32b deskjet djet500 laserjet ljetplus
ljet2p ljet3 ljet3d ljet4 ljet4d lj5mono lj5gray cdeskjet cdjcolor
cdjmono cdj550 pj pjxl pjxl300 uniprint ijs bj10e bj200 bjc600 bjc800
faxg3 faxg32d faxg4 pcxmono pcxgray pcx16 pcx256 pcx24b pcxcmyk pbm
pbmraw pgm pgmraw pgnm pgnmraw pnm pnmraw ppm ppmraw pkm pkmraw pksm
pksmraw tiffcrle tiffg3 tiffg32d tiffg4 tifflzw tiffpack tiff12nc
tiff24nc psmono psgray psrgb bit bitrgb bitcmyk png16m pnggray pngmono
png256 png16 jpeg jpeggray pdfwrite pswrite epswrite pxlmono pxlcolor
appledmp ccr cdj1600 cdj500 cdj670 cdj850 cdj890 cdj970 cgm24 cgm8
cgmmono cif cp50 declj250 dfaxhigh dfaxlow djet500c dl2100 dnj650c
eps9high eps9mid epson epsonc hl7x0 ibmpro imagen inferno iwhi iwlo iwlq
jetp3852 la50 la70 la75 la75plus lbp8 lips3 lj250 lj4dith ln03 lp2563
lp8000 lq850 lxm5700m m8510 mgr4 mgr8 mgrgray2 mgrgray4 mgrgray8 mgrmono
miff24 necp6 oce9050 oki182 okiibm paintjet pjetxl plan9bm r4081 sgirgb
sj48 st800 stcolor sxlcrt t4693d2 t4693d4 t4693d8 tek4696 xes cljet5
cljet5c nullpage
Search path:
. : /home/panov/.kde/share/fonts : /usr/share/ghostscript/7.05/lib :
/usr/share/ghostscript/fonts
For more information, see /usr/share/ghostscript/7.05/doc/Use.htm.
Report bugs to bu...@gh..., using the form in Bug-form.htm.
I think this is caused by incompatiblity in gs versions.
--
Andrey V. Panov
panov /AT/ iacp.dvo.ru
http://canopus.iacp.dvo.ru/~panov/
|
|
From: Andrey V. P. <pa...@ia...> - 2002-07-11 20:50:15
|
It seems that textrace (as of version 0.49) does not work with GNU gs 7.05, at least Slackware 8.1 binary. -- Andrey V. Panov panov /AT/ iacp.dvo.ru http://canopus.iacp.dvo.ru/~panov/ |
|
From: Vladimir V. <vv...@vs...> - 2002-03-11 10:15:55
|
Hi Peter, "SP" == Szabo Peter writes: >> 2) with new sfrm1000.pfb produced by type1fix.pl (209628 bytes): $ >> dvips test -o This is dvips(k) 5.86e Copyright 2001 Radical Eye >> Software (www.radicaleye.com) ' TeX output 2002.03.11:1835' -> >> test.ps >> <texc.pro><cm-super-t1.enc><texps.pro>. <cmr10.pfb><sfti1000.pfb> >> Second number not found in Char string of '/q' SP> My version of dvips 5.86e (Debian Sid) works just fine, so I SP> wasn't able to reproduce the error. Peeking in the dvips sources, SP> the Second number... message is a generic and low-level error; SP> the real bug is higher, so it would need recompilation and SP> debugging (for which I don't have time). i tested the current development version of dvips compiled from texlive repository, and it works fine: $ dvips --version dvips(k) 5.86f kpathsea version 3.3.7 Copyright (C) 2001 Radical Eye Software. There is NO warranty. You may redistribute this software under the terms of the GNU General Public License and the Dvips copyright. For more information about these matters, see the files named COPYING and dvips.h. Primary author of Dvips: T. Rokicki; -k maintainer: T. Kacvinsky/ S. Rahtz. $ dvips test -o This is dvips(k) 5.86f Copyright 2001 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.03.11:2058' -> test.ps <texc.pro><cm-super-t1.enc><texps.pro>. <cmr10.pfb><sfti1000.pfb>[1] SP> I strongly recommend running type1fix.pl until the final version SP> of your fixing script is ready. SP> Replying to my own words: please give parameters to type1fix.pl SP> _exactly_ the same way TeXtrace does; don't forget SP> --dump-spaces=no. ok, i'll try that -- but i tried to make cm-super fonts compliant to the standard described in the adobe specs (and even to the stricter atm-compatibility standard), and i do not see what is technically wrong in the cm-super PFB files which type1fix might improve. could you please look at the fonts and tell me what may be wrong? >> but - even with type1fix, i got an error, - so i do not see >> advantage. :) and after type1fix, the fonts became significantly >> bigger. SP> Advantage: type1fix.pl works _unless_ you're in a very specific SP> situation: SP> -- dvips 5.86e -- -j -- you have the buggy dvips 5.86e SP> So I still recommend it. i'll test further with dvips 5.86 from teTeX beta. if i recall correctly, Tom Kacvinsky and i tried hard and failed to see what's wrong with cm-super fonts, and it appeared that the bug was in dvips. but - there is already a known bug in all dvips versions except the current development version which will appear in TeX Live 7 and the next teTeX: one PFB font cannot be correctly re-encoded to several font encodings in one document. SP> The file size increase of type1fix.pl is strange (it shouldn't SP> be), I'll have a look at it after both of us is convinced that SP> the output is compatible. Currently, after removing the /Encoding SP> array, my .pfb is 196752 bytes, sfti1000.pfb is 186500 SP> bytes. There should be only 1000 bytes of difference maximum :-(. part of this size is an extra space which type1fix emits at the end of each charstring (in subrs and in charstrings). Best, v. |
|
From: Vladimir V. <vv...@vs...> - 2002-03-11 07:48:54
|
Dear Peter, "SP" == Szabo Peter writes: >> what are the compatibility problems which you observe with the >> cm-super pfb files? i think i can fix them by perl perprocessor >> used on a final stage before running t1asm. SP> I've written type1fix.pl to eliminate 8--13 common portability SP> issues of Type1 fonts. Example: SP> \font\f=sfti1000 SP> \f Hello, World! \end first of all, there is no such TeX font sfti1000.tfm -- the cm-super fonts need to be re-encoded to one of supported font encodings (T1, TS1, T2A, T2B, T2C). So i changed the line \font\f=sfti1000 to \font\f=ecti1000 SP> This is dvips(k) 5.86 Copyright 1999 Radical Eye Software SP> (www.radicaleye.com) ' TeX output 2002.03.11:1504' -> |lpr SP> <texc.pro><texps.pro>. <sfti1000.pfb> Error: 135326408 Subr not SP> found SP> After running through type1fix.pl: SP> This is dvips(k) 5.86 Copyright 1999 Radical Eye Software SP> (www.radicaleye.com) ' TeX output 2002.03.11:1504' -> t.ps SP> <texc.pro><texps.pro>. <sfti1000.pfb>[1] i tried this, and here is what i got: 1) with original sfrm1000.pfb (186500 bytes): $ dvips test -o This is dvips(k) 5.86e Copyright 2001 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.03.11:1835' -> test.ps <texc.pro><cm-super-t1.enc><texps.pro>. <cmr10.pfb><sfti1000.pfb> Error: 1625600 Subr not found 2) with new sfrm1000.pfb produced by type1fix.pl (209628 bytes): $ dvips test -o This is dvips(k) 5.86e Copyright 2001 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.03.11:1835' -> test.ps <texc.pro><cm-super-t1.enc><texps.pro>. <cmr10.pfb><sfti1000.pfb> Second number not found in Char string of '/q' DVIPS works with "-j0" option. otherwise, current versions of dvips have some bugs in parsing Type 1 fonts, including inability to re-encode the same Type 1 font to several encodings (e.g. if you have used ecti1000 and tcti1000 which are re-encoded from the same file sfrm1000.pfb). PdfTeX works much better. these bugs in dvips are now fixed in development versions (by using type1 preloader from pdftex). SP> Please read TeXtrace doc/type1fix.txt for more information. I can SP> help you testing portability of the CM-Super fonts by trying SP> those with the utilities mentioned in doc/type1fix.txt. thanks, i'll examine this document. SP> I strongly recommend running type1fix.pl until the final version SP> of your fixing script is ready. but - even with type1fix, i got an error, - so i do not see advantage. :) and after type1fix, the fonts became significantly bigger. SP> I also welcome patches to TeXtrace that would produce SP> t1asm-compatible input files, so the users would have a choice SP> between speed and compatibility. (I am also interested in your SP> fixing script.) i'll send some additional scripts which may be of use to TeXtrace and pktrace, after i get some time to arrange them in a good form. Best, v. |
|
From: Szabo P. <pt...@in...> - 2002-03-11 06:19:11
|
Dear Vladimir, > what are the compatibility problems which you observe with the > cm-super pfb files? i think i can fix them by perl perprocessor used > on a final stage before running t1asm. I've written type1fix.pl to eliminate 8--13 common portability issues of Type1 fonts. Example: \font\f=sfti1000 \f Hello, World! \end This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.03.11:1504' -> |lpr <texc.pro><texps.pro>. <sfti1000.pfb> Error: 135326408 Subr not found After running through type1fix.pl: This is dvips(k) 5.86 Copyright 1999 Radical Eye Software (www.radicaleye.com) ' TeX output 2002.03.11:1504' -> t.ps <texc.pro><texps.pro>. <sfti1000.pfb>[1] Please read TeXtrace doc/type1fix.txt for more information. I can help you testing portability of the CM-Super fonts by trying those with the utilities mentioned in doc/type1fix.txt. I strongly recommend running type1fix.pl until the final version of your fixing script is ready. I also welcome patches to TeXtrace that would produce t1asm-compatible input files, so the users would have a choice between speed and compatibility. (I am also interested in your fixing script.) Best regards, pts --- (vvv use GNU); pt...@in...; http://www.inf.bme.hu/~pts [/dlflg/=u]dZ[lalbdlp*lqlg*+lpla*lqlf*+lflgsbsasfsglex]dscZ[r%O*]sdzzKsa [nlbdlaldxlglfldxsfdsalex]dsuZ[.]zsqsssgsbnsfspselsn[lcxsslqdlp+spz+sqdx]dx |
|
From: Szabo P. <pt...@fa...> - 2002-03-11 06:01:50
|
Thank you for the news. I've updated the distribution and the web site (www.inf.bme.hu/~pts/textrace/) On Fri, 1 Mar 2002, Daniel Richard G. wrote: > Hello, > > First off, thank you for your work on TeXtrace; it's an immensely powerful > tool that was greatly needed in the TeX and Metafont communities. > > I was also thrilled at the additional effort you had made in creating the > Tt2001 font set, and with your mention of having uploaded it to CTAN, I > could only why it hadn't yet shown up on the mirror sites. When I searched > Usenet about it, however, I learned about Vladimir Volovich's cm-super > package---already in CTAN. > > If I could ask a small favor: Could you update doc/textrace.txt and the > TeXtrace home page to reflect availability of the cm-super font set? > Because I didn't know about it, I thought that I would have had to wait for > Tt2001 to stabilize (and show up on CTAN) in order to be able to use Type 1 > EC fonts. Surely other folks are in a similar situation, and would be very > happy to learn about cm-super. > > I would suggest adding a link to the cm-super file list, as no proper home > page seems to exist for it: > > http://www.ctan.org/tex-archive/fonts/ps-type1/cm-super/ > > > Also, do you intend on completing development of the Tt2001 fonts and > uploading them to CTAN, or have you abandoned the effort, now that > cm-super exists? > > > Sincerely yours, > > > --Danny > > > -- > NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef? > EMAIL1 = skunk@******.org ## don't smell bad--- (/o|o\) / > EMAIL2 = sk...@al... ## it's the people who < (^),> > WWW = http://www.******.org/ ## annoy them that do! / \ > -- > (****** = site not yet online) > --- pt...@fa...; http://www.inf.bme.hu/~pts/ vvv http://www.geekcode.com -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d s+:- a-- C++ ULS+++ P+++(++++) L+++ E- W++(--) N* o+ K? w-(--) O? M- V>++ PS+ PE Y+ PGP t? S? X(+) R tv b+>++ DI? D G e+ h-- ------END GEEK CODE BLOCK------ |
|
From: Han-Wen N. <ha...@cs...> - 2002-02-05 15:58:50
|
INTRODUCTION pktrace is a small Python program that lets you trace a PK font into a PFA or PFB font (PostScript Type1). It is licensed under the GNU GPL. Type1 fonts offer many advantages over bitmaps, as they allow PostScript files to render correctly on printers with many resolutions. Moreover, Ghostscript can generate much better PDF, if given scalable fonts. See http://www.cs.uu.nl/~hanwen/pktrace/ or download it at http://www.cs.uu.nl/~hanwen/pktrace/pktrace-0.6.tar.gz WHAT'S NEW pktrace now no longer requires Perl or Ghostscript; it now uses t1asm to construct the PFA file. This version does not share any code with textrace anymore. -- Han-Wen Nienhuys | ha...@cs... | http://www.cs.uu.nl/~hanwen/ |
|
From: Jan O. <min...@gm...> - 2002-01-23 19:29:00
|
Hi, TeXtrace basically works fine for me; I'm currently trying to convert the bbm fonts. The bbm letters are partly hollow, and unfortunately only the outline gets traced and not the inner 'holes' (or maybe they do get traced but are not converted correctly). I updated autotrace to 0.29, but that didn't change it. Well, I haven't dug too deeply into textrace so maybe I'm just missing something simple. How do I make textrace/autotrace properly convert those characters? Thanks in advance, Jan -- +-------------------------------------+ | Jan Oberländer <min...@gm...> | | PGP key available | +-------------------------------------+ |
|
From: Mirko S. <Sr...@we...> - 2001-12-13 22:23:23
|
Hi, when you convert fonts with less characters (like eurosyms or duerer) TeXtrace produces foreach not specified letter an entry. So I wrote a Perl-program that deletes them by using the t1utils (1.24) package. It takes two arguments the input PFB file and the output PFB file hope it is useful mirko attatched: source of pfb_strip.pl |
|
From: Szabo P. <pt...@in...> - 2001-12-13 00:09:40
|
Dear Philip, On Wed, 12 Dec 2001, Philip A. Viton wrote: > > It looks to me as if the concrete fonts in the Tt2001 collection > (eg fcr10.pfb ) are missing the letters "i" and "j". (checked using > Ghostscript's prfont utility). Can anyone confirm this? I reported the > matter privately to P. Szabo a couple of days ago, but there's been no > response. Sorry for not answering earlier. Yes, the concrete fonts are buggy, please re-generate the with the latest TeXtrace. --- (vvv use GNU); pt...@in...; http://www.inf.bme.hu/~pts [/dlflg/=u]dZ[lalbdlp*lqlg*+lpla*lqlf*+lflgsbsasfsglex]dscZ[r%O*]sdzzKsa [nlbdlaldxlglfldxsfdsalex]dsuZ[.]zsqsssgsbnsfspselsn[lcxsslqdlp+spz+sqdx]dx |
|
From: Philip A. V. <pv...@ma...> - 2001-12-12 08:08:38
|
It looks to me as if the concrete fonts in the Tt2001 collection (eg fcr10.pfb ) are missing the letters "i" and "j". (checked using Ghostscript's prfont utility). Can anyone confirm this? I reported the matter privately to P. Szabo a couple of days ago, but there's been no response. ------------------------ Philip A. Viton City Planning, Ohio State University 190 W. 17th Ave,Columbus OH 43210 vi...@os... |
|
From: Szabo P. <pt...@in...> - 2001-11-26 02:39:17
|
Dear Peter, > 3) Trying to use pfaedit on the pfb I get problems: The element/font > info/encoding says the font contains 257 characters (instead of > metafont's max. of 256). The font Encoding actually has exactly 256 characters. Just count them for yourself. (The font has 257 character, 256 is part of the Encoding, and 1 single /.notdef is not part of it.) element/font info/encoding is probably a bug in pfaedit. Anyway, pfaedit is really bad when trying to read a font with an _embedded_ encoding. Contact the author of pfaedit to get it fixed. > 4) Looking at the console output during traceall.sh I note that > type1fix.pl reports "Packed 257 characters". That's because an extra /.notdef is inserted into the font file (not part of the Encoding). The Encoding has exactly 256 characters. > 5) Is there possibly an off-by-one error in here somewhere? If so, you > should get it with any MF-generated font... Maybe, but as to my present knowledge, TeXtrace works OK, and pfaedit is buggy. Maybe you should extract the Encoding from the .pfb file with a tool shipped with TeXtrace (contrib/*.pl), install it as a user-defined pfaedit encoding, and open the font with that encoding. Peter --- (vvv use GNU); pt...@in...; http://www.inf.bme.hu/~pts [/dlflg/=u]dZ[lalbdlp*lqlg*+lpla*lqlf*+lflgsbsasfsglex]dscZ[r%O*]sdzzKsa [nlbdlaldxlglfldxsfdsalex]dsuZ[.]zsqsssgsbnsfspselsn[lcxsslqdlp+spz+sqdx]dx |
|
From: Peter D. <pd...@ho...> - 2001-11-23 15:59:47
|
I _think_ this a a real bug, but I'm pretty new to TeX font
manipulation:
1) Using traceall.sh on a working TeX bitmap font (e.g. font=ifsym10
from ctan/fonts/ikloeckl; this is a metafont generated font).
2) The resulting pfb works fine under TeX/LaTeX (the autotracing is
*great*!).
3) Trying to use pfaedit on the pfb I get problems: The element/font
info/encoding says the font contains 257 characters (instead of
metafont's max. of 256). This apparently confuses pfaedit when it
saves the font -- the 1st character gets dropped (slot for 'grave')
[pfaedit may have it's own bugs, too.]
4) Looking at the console output during traceall.sh I note that
type1fix.pl reports "Packed 257 characters". The file tmpdump.dvi
contains only 256 pages as expected. See around line # 4879 in
type1fix.pl.
5) Is there possibly an off-by-one error in here somewhere? If so, you
should get it with any MF-generated font...
Attached is a silly (but small!) example. The font, grampa, is just the
metafont example from Hoenig's "TeX Unbound", page 62. The tar.gz
contains the mf source and the textrace pfb. pfaedit shows it as
containing 257 characters (2 non-blank as expected).
If you need it (large file), I've preserved the tmp directory generated
by textrace for both the grampa and ifsym10 cases.
As I said in (2), the pfbs work fine under LaTeX, but editing them with
pfaedit is a problem. I don't think I can just reencode the ifsym
font(s) because ifsym.sty accesses the characters by \symbol{XX}.
Many thanks,
peter denisevich
|
|
From: Szabo P. <pt...@fa...> - 2001-11-14 10:52:14
|
Hi! > I am using a couple of fonts created with textrace 0.47. It turns out > there are some problems with those fonts, that do not show up in > ghostscript or Acrobat, but in some other less forgiving systems they > do. Thanks for reporting the bug, but unfortunately the information you supplied is not enough even for identifying it. Please send the .pfb file generated by TeXtrace. Also please send a bitmap file of the EXPECTED result, and a bitmap file for the result with GS. Render the files so the difference will be visible without magnification. Please explain (by words) what the difference is, and how the generated font is wrong. Please also read the TeXtrace documentation about reporting bugs. Please forward this reply to your wizards. > Begin forwarded message: > > > From: "Frank M. Siegert" <fr...@wi...> > > Date: Fri Nov 09, 2001 08:13:22 Europe/Amsterdam > > To: Gerben Wierda <she...@rn...> > > Cc: Andrew Stone <an...@st...> > > Subject: Re: Pstill > > > > > Hi and Thanks Gerben, > > > > I can only advise not to use type1fix.pl or textrace - the fonts (all > > of the textrace generated inside it seems) are really not quite ok - > > the ams fonts are not a problem! > > > > Here are the main problems: > > > > - it accesses read only directories within itself at runtime and tries > > to put values there. Looks like other interpreter does not check for > > this in an EEXEC decode run. However this is not a documented feature. What?? Where? Who? Which TeXtrace version? Which dictionary? Which font? (This should be a serious bug. Its very strange I haven't noticed it yet.) > > - it lacks the required (PostScript Language Reference Manual, Chapter > > 5.1) 'FontBBox' entry! I've verified it with TeXtrace 0.47 and it inserts the FontBBox entry properly. Please forget older versions once and for all. (TeXtrace 0.45 is quite OK, but it's almost the same as 0.47.) > > [contact the author of textrace] > > of course you can do this. He can also contact me for questions. Right > > now > > just tell him that per PLRM (PsotScript Language Reference Manual) > > Section > > 5.1 a Type 1 font must have the entry /FontBBox [...] - it can be a zero > > entry ( /FontBBox [ 0 0 0 0 ] def ) but may not be omitted otherwise the > > font may or may not run on PS devices. A lot devices tend to forgive > > this > > (GhostScript) but other do not, even those forgiving may run into > > troubles > > later. Thanks, I know it and TeXtrace already works according to this. If not, that should be a serious unnoticed, unintended bug. Please give specific examples when it goes wrong. > Furthermore, both pdfTeX and ghostscript produce strange output with the > 0.47 textrace fonts (where 0.42 at least looked ok even if there were > problems with the fonts) What fonts? I have converted more than 500 fonts and they all work fine for me in all gs, pdftex, acroread, dvipdfm, fontographer, fontlab, pfaedit, atm, xpdf. (It is indeed possible that there is still a bug which hasn't affected my 500 fonts, so don't hesitate to report it.) Regards, pts --- pt...@fa...; http://www.inf.bme.hu/~pts/ vvv http://www.geekcode.com -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d s+:- a-- C++ ULS+++ P+++(++++) L+++ E- W++(--) N* o+ K? w-(--) O? M- V>++ PS+ PE Y+ PGP t? S? X(+) R tv b+>++ DI? D G e+ h-- ------END GEEK CODE BLOCK------ |
|
From: Han-Wen N. <ha...@cs...> - 2001-11-12 05:13:52
|
vv...@vs... writes:
> isn't it better to fix autotrace than to apply a workaround? if you
> have a specific glyph bitmap which makes original autotrace to dump
> core, than it will be much better to fix autotrace.
Indeed. I'm currently running the EC fontset through PK trace right
now, to find any anomalies.
Incidentally, I released a new PKTrace today, which is even faster
than the previous version.
0.2:
* Don't read/write dimension file.
* Read encoding file into python, and only once. This reduces
tracing time, and allows different .enc files.
* For non-existant glyphs, write fake Char String directly.
http://www.cs.uu.nl/~hanwen/pktrace/index.html
--
Han-Wen Nienhuys | ha...@cs... | http://www.cs.uu.nl/~hanwen/
|
|
From: Vladimir V. <vv...@vs...> - 2001-11-12 04:44:00
|
"SP" == Szabo Peter writes:
>> calling AutoTrace with the option background-color FFFFFF should
>> do the same on pictures
SP> No. without background-color autotrace dumps cure with a
SP> segfault. With background-color there are much less segfaults.
[...]
>> if (SPLINE_LIST_LENGTH(list)<2) { shouldn't be neccessary. If this
>> appears there is a bug in AutoTrace in the fitting routine.
SP> Correct. TeXtrace has to work even if autotrace is buggy. Maybe
SP> that single line is even unnecessary, but I as far as I remember
SP> there was a specific case which produced a segfault without that
SP> single line, and worked without it. (Mabe the constant was 3, not
SP> 2...)
SP> For me (and for TeXtrace), autotrace works better _with_ the
SP> patch. If someone doesn't apply the patch, there is a chance of
SP> 0.2% (or so) for each glyph that autotrace segfaults. With the
SP> patch, the chance is 0.0% (I've not found any failing glyph.) So
SP> I absolutely recommend the patch for TeXtrace users.
SP> Actually the patch (and background-color) is ugly, but there is
SP> no doubt that we _must_ use it in order to make things _always_
SP> work.
isn't it better to fix autotrace than to apply a workaround? if you
have a specific glyph bitmap which makes original autotrace to dump
core, than it will be much better to fix autotrace.
Best,
v.
|
|
From: Szabo P. <pt...@in...> - 2001-11-12 02:41:43
|
Dear all,
> and also produces sometimes wrong results
Exactly when is the patch wrong?
> My opinion is that this patch isn't neccessary
It is necessary because autotrace would dump core with a segfault without
it for some glyphs.
> calling AutoTrace with the option background-color FFFFFF should do the
> same on pictures
No. without background-color autotrace dumps cure with a segfault. With
background-color there are much less segfaults.
Also: white regions are prohibited in type1 outlines. We _must_ describe
what is _black_. So visually it they are the same, but technically
they are very different.
> if (SPLINE_LIST_LENGTH(list)<2) {
> shouldn't be neccessary. If this appears there is a bug in AutoTrace in
> the fitting routine.
Correct. TeXtrace has to work even if autotrace is buggy. Maybe that
single line is even unnecessary, but I as far as I remember there was a
specific case which produced a segfault without that single line, and
worked without it. (Mabe the constant was 3, not 2...)
For me (and for TeXtrace), autotrace works better _with_ the patch. If
someone doesn't apply the patch, there is a chance of 0.2% (or so) for
each glyph that autotrace segfaults. With the patch, the chance is 0.0%
(I've not found any failing glyph.) So I absolutely recommend the patch
for TeXtrace users.
Actually the patch (and background-color) is ugly, but there is no doubt
that we _must_ use it in order to make things _always_ work.
--- (vvv use GNU); pt...@in...; http://www.inf.bme.hu/~pts
[/dlflg/=u]dZ[lalbdlp*lqlg*+lpla*lqlf*+lflgsbsasfsglex]dscZ[r%O*]sdzzKsa
[nlbdlaldxlglfldxsfdsalex]dsuZ[.]zsqsssgsbnsfspselsn[lcxsslqdlp+spz+sqdx]dx
|
|
From: Szabo P. <pt...@in...> - 2001-11-06 06:14:47
|
--- (vvv use GNU); pt...@in...; http://www.inf.bme.hu/~pts [/dlflg/=u]dZ[lalbdlp*lqlg*+lpla*lqlf*+lflgsbsasfsglex]dscZ[r%O*]sdzzKsa [nlbdlaldxlglfldxsfdsalex]dsuZ[.]zsqsssgsbnsfspselsn[lcxsslqdlp+spz+sqdx]dx |
|
From: Han-Wen N. <ha...@cs...> - 2001-11-05 07:29:20
|
pt...@fa... writes: > > > > "download and install pktrace" > > OK, maybe I'll add an install script soon. > actually, it would be very easy; what you do, is to make a temporary directory using mktemp, and cd to it. Remove all of the leading "tmp/" references (eg. tmp/tmp_char.eps) from the script, and make other paths absolute. -- Han-Wen Nienhuys | ha...@cs... | http://www.cs.uu.nl/~hanwen/ |
|
From: Szabo P. <pt...@fa...> - 2001-11-05 07:16:56
|
> I'm the author of LilyPond, a program for typesetting music. Since our > font changes regularly, we want to trace pfb's as part of the > compilation process. For the people who download it, it's easier to > say > > "download and install pktrace" OK, maybe I'll add an install script soon. > > (which uses a standard configure, > make, make install sequence), than It's not so easy with most software. One has to hack it to make it work. But the principle is nice. > At some point, a Linux distribution might package pktrace, and then > installing and uninstalling it is boils down to The coders of those distributions are smart enough to make TeXtrace installable in 1--2 hours of work in the way _they_ like it. > Or even better: it might already be installed as a part of a tex > distribution. No instructions needed Yep. > BTW, you can always install well-behaved packages and remove them with > a single rm -rf. The trick is to configure with > --prefix=$HOME/usr/pkg/PACKAGENAME, and to symlink from ~/usr/bin/ to > ~/usr/pkg/*/bin/ (by a script). Removing a package is as simple as cd > ~/usr/pkg/; rm -rf PACKAGENAME. In fact, if I don't have RPM > packages, this is how I always install every package, be it "for real" > or "for trying". Thx. > Interesting, I've seen references to .vf earlier, but do you know > where I can read up on them? Virtual fonts: WEB docs of vftovp and vptovf utilities, + knuth's mail on CTAN (I don't know where). > Well, to tell you the truth: I'm kind of fascist when it comes to > brain-damaged software (let the users upgrade :), but I'll have a > look. It's just 5 verbatim lines. Simply inculde it, it does magic. Your program can be used even if the administrator is incapable or reluctant to upgrade. > BTW, I asked Martin Weber about integrating your .bps patch into > autotrace. He said he'll have a look next week. Thanks again. --- pt...@fa...; http://www.inf.bme.hu/~pts/ vvv http://www.geekcode.com -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d s+:- a-- C++ ULS+++ P+++(++++) L+++ E- W++(--) N* o+ K? w-(--) O? M- V>++ PS+ PE Y+ PGP t? S? X(+) R tv b+>++ DI? D G e+ h-- ------END GEEK CODE BLOCK------ |
|
From: Szabo P. <pt...@fa...> - 2001-11-05 05:31:54
|
Hi!
> the purpose of pktrace is to be used standalone. My main gripe with
> textrace is that can't be installed. Some more discussion is in the
> README of pktrace (note that I've just released pktrace-0.1) :
I'm happy that you found TeXtrace useful and I'm even happy that
pktrace has been born. I'm not sure which utility I will use for my next
conversion task, and also I'll recommend both of them for newbies. (Please
give me a version-independent URL I can put onto TeXtrace's home page.)
Let's compare the two utilities again:
-- pktrace is clearly written. TeXtrace just works.
Clean design was not the (primary) goal of TeXtrace. TeXtrace should be
compatible (even with ancient Unix and teTeX distributions), and it
should _work_. Only if it _works_, then it should be cleanly designed.
Probably I can eliminate Bash/Zsh (in favour of Perl). But I cannot
eliminate PostScript or C. So it is _impossible_ to rewrite it much
cleaner even if I had time.
-- pktrace is more quiet by default. TeXtrace always gives feedback.
Maybe I can add a --verbose option (or more preferably: a non-default
--no-verbose option) to TeXtrace. But I don't think it is worth the
time, because (1) if everything works OK, the user just ingores any
output and looks at the last few lines that indicate full success.
("CHECK: OK" means: ghostscript has verified the Type1 syntax and
rendered all glyphs into a memory buffer -- so the font is
syntactically and schemantically correct.) (2) if something goes wrong,
the novice user just gives up, but the advanced user _needs_ the debug
messages. TeXtrace is verbose deliberately. TeXtrace gives feedback.
(It's a bit philosophy, but only a little bit.)
-- pktrace is easier to install. TeXtrace has minimal dependencies.
TeXtrace does assume the absolute minium of your confiuguration:
-- Perl
-- Bash/Zsh Shell
-- cp, rm etc. shell utilities
-- working tex on $PATH
-- working dvips on $PATH
-- working gs on $PATH
-- autotrace _or_ an ansi C compiler
pktrace needs
-- python
-- pk2bm
-- gs
-- patch
-- C compiler
-- shell (for the configure script)
-- perl (for type1fix.pl)
-- metafont (?? maybe not required? ttf2pk should be enough??)
-- install
-- kpsewhich (or the user should know where the .pk files are. But not
everybody is a TeX expert to know it.)
-- make
TeXtrace is almost self-contained. It depends on only widely available
software. (Particularly, it doesn't depend on an installed AutoTrace
or Python or kpsewhich or make.)
-- pktrace can be installed. TeXtrace works out of the box.
OK, TeXtrace cannot be installed. But I think this is not a huge
disadvantage, because you cannot do your job significantly faster even
if you save re-compilation time. Actually I prefer programs that work
_without_ installing. So I don't have to be root or specify special
configure switches to just try it and rm -rf it if I don't like it.
-- pktrace supports only PK font input. TeXtrace accepts any TeX font input.
Particularly, pktrace doesn't support TeX .vf virtual fonts, and it
would be hard for me to add support.
TeXtrace supports virtual fonts since no distinction is made between
normal and virtual ones. (useless:) TeXtrace also supports Type1
input (via dvips), TrueType font input (via ttf2pk).
-- pktrace has an --encoding option. type1fix.pl has the --inencfile
option.
The user can really change the encoding if (s)he wants to. But most of
the time the .pfb output will be used by dvips, dvipdfm and pdftex:
none of them look at the /Encoding unless the user explicitly wants it.
Also specifying a proper /Encoding requires expert level knowledge from
the user.
-- pktrace comes with a configure script. TeXtrace just works.
Although having configure.in is a cleaner approach, it doesn't give any
more functionality or compatibility, or at least not in TeXtrace.
However, TeXtrace does some basic run-time configuration, each time it
is run.
> > textrace works on those platforms and tex distributions for which
> > there is no kpathsea that will find the .pk files on disk.
>
> fixed for pktrace 0.1 (using --encoding=FILE.enc, and --tfmfile=FILE.tfm)
But it still requires knowledge from the user. TeXtrace doesn't require
such knowledge.
I have a final remark. Please do not delete the 1st line (with #!) of
type1fix.pl, and run with `perl -x ./type1fix.pl'. That is the most
compatible and portable way to run Perl scripts, even with brain-damaged
old unices.
My conclusion is that both TeXtrace and pktrace are useful; both of them
have features the other one doesn't have, and they are both small enough
to have installed/copied on any computer. It might be possible to
integrate them and have all features (and compatibility) in a single
program, but I don't think that the code can be kept clean _and_
compatible _and_ portable in the same time. The current best choice for
the users to have both and choose from them in a project-by-project basis.
I'm also personally happy that I've managed to create something useful
and inspirative. As far as I know TeXtrace is the 1st implementation of a
generic, free font tracer. It is both a proof that it can be done and both
useful software that fulfills the promisies. Making/rewriting the code
cleaner, faster and more user friendly is important, and is possible to be
done piece-by-piece. Maybe the final result would have no common code with
the original (only type1fix.pl in pktrace--TeXtrace), but I'm not
disappointed about it. I will probably not modify TeXtrace for a while
(couple of months -- or yers) because I have already converted the fonts I
needed and I can deduce from the feedbacks that there is no serious bug or
limitation that makes it unusable.
I wish you success with pktrace. Make it a better, faster, cleaner program
than TeXtrace.
Best wishes,
pts
--- pt...@fa...; http://www.inf.bme.hu/~pts/ vvv http://www.geekcode.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d s+:- a-- C++ ULS+++ P+++(++++) L+++ E- W++(--) N* o+ K? w-(--) O?
M- V>++ PS+ PE Y+ PGP t? S? X(+) R tv b+>++ DI? D G e+ h--
------END GEEK CODE BLOCK------
|
|
From: Han-Wen N. <ha...@cs...> - 2001-11-03 08:50:33
|
pt...@fa... writes: > > I ended up with rewriting the traceall.sh script in Python. You can > > find a preliminary version of it at > > http://www.cs.uu.nl/~hanwen/public/software/pktrace-0.0.tar.gz > > OK, I'll have a look at it. If you'd like, it will be included in > the contrib section of the textrace distribution. (Please write a short > docs about it and how it differs from textrace.) the purpose of pktrace is to be used standalone. My main gripe with textrace is that can't be installed. Some more discussion is in the README of pktrace (note that I've just released pktrace-0.1) : Why use pktrace? * pktrace is a clearly written, single python script, whereas textrace is a hard to follow collection of bash scripts, perl scripts and C programs. * pktrace is more quiet by default. * The design of pktrace is cleaner: it extracts bitmaps from the PK file directly, and does not require DVIPS. That should also make it a little faster. * You can select different encodings for the font through the --encoding option. * PKtrace comes with a configure script and a Makefile with an install target. When run, temporary files are kept in /tmp, and they are removed afterwards. > I've deliberately walked the harder way with textrace. textrace works when > one doesn't have any .pk files at all. For example when the .pk files > aren't pre-generated _or_ one uses a Type1 font source (rare but possible > case). In the 1st case, you can still extract from the PK file. The 2nd case seems rather silly to me: why trace a font when you already have the Type1 outline? In any case, I would say that going from Type1 to a bitmap could be done easier than through the tex -> dvips -> gs route. > textrace works on those platforms and tex distributions for which > there is no kpathsea that will find the .pk files on disk. fixed for pktrace 0.1 (using --encoding=FILE.enc, and --tfmfile=FILE.tfm) > > Also, I noticed that autotrace > > doesn't include your patch for .bps output. Have you tried to get it > > into autotrace? > > No, because at the time I wrote TeXtrace, autotrace was temporarily > unavailable. I don't plan integration because it would require lot of > maintenance time. If you wish to do it, just do it (I give you the > permission :-), OK, I'll talk to the autotrace guy. -- Han-Wen Nienhuys | ha...@cs... | http://www.cs.uu.nl/~hanwen/ |
|
From: Szabo P. <pt...@fa...> - 2001-10-31 11:37:57
|
> I ended up with rewriting the traceall.sh script in Python. You can > find a preliminary version of it at > http://www.cs.uu.nl/~hanwen/public/software/pktrace-0.0.tar.gz OK, I'll have a look at it. If you'd like, it will be included in the contrib section of the textrace distribution. (Please write a short docs about it and how it differs from textrace.) > Maybe > you can take a look at it: it is 3 times shorter than the original, > and extracts the bitmaps directly from the pkfiles, bypassing slow and > length tex -> dvips -> ghostscript -> {pbm,bbox} process. I've deliberately walked the harder way with textrace. textrace works when one doesn't have any .pk files at all. For example when the .pk files aren't pre-generated _or_ one uses a Type1 font source (rare but possible case). textrace works on those platforms and tex distributions for which there is no kpathsea that will find the .pk files on disk. > It still relies on the t1d2gsx and type1fix script and trace2.ps -- > but I was wondering: what do they do? Please read the documentation shipped with the software. Basicly type1fix converts Type1 to better Type1, and t1d2gsx puts Type1 syntax (not information, just syntax) around t1d glyph outlines. Please read the extensive documentation of type1fix.pl shipped with textrace. > Especially type1fix seems > enormous. What was it generated from? It was generated from smaller perl scripts in a straightforward way. You can easily find boundaries /^package .*/. > Also, I noticed that autotrace > doesn't include your patch for .bps output. Have you tried to get it > into autotrace? No, because at the time I wrote TeXtrace, autotrace was temporarily unavailable. I don't plan integration because it would require lot of maintenance time. If you wish to do it, just do it (I give you the permission :-), you can be the official autotrace maintainer for TeXtrace.). Anyway, I've modified the configure script for autotrace so it doesn't stupidly break while badly detecting unnecessary libraries. (autotrace in textrace is linked against only the libs, even if you have tons of libpng etc. libraries installed -- textrace simly doesn't need it). --- pt...@fa...; http://www.inf.bme.hu/~pts/ vvv http://www.geekcode.com -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d s+:- a-- C++ ULS+++ P+++(++++) L+++ E- W++(--) N* o+ K? w-(--) O? M- V>++ PS+ PE Y+ PGP t? S? X(+) R tv b+>++ DI? D G e+ h-- ------END GEEK CODE BLOCK------ |
|
From: Szabo P. <pt...@in...> - 2001-10-27 09:15:09
|
Hi! > Fairly quick on my machine at home too. I am interested in making it > work on win32 - when I have some time I'll play and let you konw the > results. Thanks. Please browse the mailing list archive (at lists.sourceforge.net), somebody has also some experiences about it. It should work with zsh + perl + miktex. You may have to put long one-liner perl scripts in traceall.sh into separate .pl files. Please report your success also onto the mailing list. pts --- (vvv use GNU); pt...@in...; http://www.inf.bme.hu/~pts [/dlflg/=u]dZ[lalbdlp*lqlg*+lpla*lqlf*+lflgsbsasfsglex]dscZ[r%O*]sdzzKsa [nlbdlaldxlglfldxsfdsalex]dsuZ[.]zsqsssgsbnsfspselsn[lcxsslqdlp+spz+sqdx]dx |
1 message has been excluded from this view by a project administrator.