Menu
▾
▴
tcl-core
|
From: T. H. <ts...@mr...> - 2008-12-13 17:50:41
|
Hi, I'm new to tcl, so apologies if this is an inappropriate list
to ask for help.
I have tcl/tk 8.5.2 on Fedora 9, and hav a curious problem using the
'postscript' command on a canvas.
I have a line like:
.c create text 200 200 -text "Hello World" -font {FreeSans 50}
in my tcltk script file, and the text displays with the correct font.
If I dump the cancas window to a file with a line like:
.c postscript -x 0 -y 0 -height $h -width $w -pagewidth 8.0i -pageheight 11.0i -pagex 4.0i -pagey
5.5i -pageanchor c -file junk2.ps
The postscript file ends up with a line like
/Freesans findfont 50 scalefont ISOEncode setfont
The FreeSans from the script has been changed to Freesans in the
postscript file and Ghostscript cant then find the font.
Short of editing all my (ttf) font files is there a fix for this?
Cheers,
Terry
|
|
From: Jan N. <nij...@us...> - 2008-12-14 08:32:41
|
At first sight, this sounds like a bug. I don't know if it is worth to
fix it, because there is a workaround, but it is useful to file
a bug report anyway. Then maybe more people can comment
on it, you can follow the eventual fix, and more people can
put comments there.
2008/12/13 T. Horsnell <ts...@mr...>:
> The FreeSans from the script has been changed to Freesans in the
> postscript file and Ghostscript cant then find the font.
The .c postscript command has an option -fontmap. According to
the manual (see below), Tk's guessing only works for well-known
fonts. Currently (at least since Tk 8.1), Tk capitalizes the first
character and changes all others to lowercase in this case. Your
problem might be a good excuse to change that behavior. Maybe
others can provide more ideas? Anyone else has an idea what's
the reason to change all other characters to lowercase? It's
easy to change that in the core, but I don't know what other
effects that would have.......
Regards,
Jan Nijtmans
=================================================
-fontmap varName
VarName must be the name of an array variable that specifies a font
mapping to use in
the Postscript. Each element of varName must consist of a Tcl list
with two elements,
which are the name and point size of a Postscript font. When
outputting Postscript
commands for a particular font, Tk checks to see if varName contains
an element with
the same name as the font. If there is such an element, then the font
information
contained in that element is used in the Postscript. Otherwise Tk
attempts to guess
what Postscript font to use. Tk's guesses generally only work for
well-known fonts
such as Times and Helvetica and Courier, and only if the X font name
does not omit
any dashes up through the point size. For example,
-*-Courier-Bold-R-Normal--*-120-*
will work but *Courier-Bold-R-Normal*120* will not; Tk needs the
dashes to parse the font name).
|
|
From: Donal K. F. <don...@ma...> - 2008-12-14 09:05:16
|
Jan Nijtmans wrote: > The .c postscript command has an option -fontmap. According to > the manual (see below), Tk's guessing only works for well-known > fonts. Currently (at least since Tk 8.1), Tk capitalizes the first > character and changes all others to lowercase in this case. Your > problem might be a good excuse to change that behavior. Maybe > others can provide more ideas? Anyone else has an idea what's > the reason to change all other characters to lowercase? It's > easy to change that in the core, but I don't know what other > effects that would have....... Postscript font names have to be PS symbols, so no spaces (and a lot of other restrictions too). The font guesser title-cases each word — you were probably testing with single-word font names — in the font name and concatenates them: "Foo Bar BooBoo tWiNkIe" -> "FooBarBoobooTwinkie" That's correct more often than not, but is imperfect. Donal. |
|
From: Alexandre F. <ale...@gm...> - 2008-12-14 11:38:49
|
On Sun, Dec 14, 2008 at 10:05 AM, Donal K. Fellows <don...@ma...> wrote: > > "Foo Bar BooBoo tWiNkIe" -> "FooBarBoobooTwinkie" > > That's correct more often than not, but is imperfect. What about special-casing the Sans, Serif and SansSerif suffixes ? -Alex |
|
From: Donal K. F. <don...@ma...> - 2008-12-14 11:51:50
|
Alexandre Ferrieux wrote: > On Sun, Dec 14, 2008 at 10:05 AM, Donal K. Fellows > <don...@ma...> wrote: >> "Foo Bar BooBoo tWiNkIe" -> "FooBarBoobooTwinkie" >> >> That's correct more often than not, but is imperfect. > > What about special-casing the Sans, Serif and SansSerif suffixes ? I don't think there's a way to do it nicely. Your suggestion wouldn't make things work any better on this system for example. Maybe if we had some way to put fallback code in the postscript prolog we could do better, but I'm not feeling very up to hacking PS at the moment. Being able to write fractional point sizes would be a reasonable update though. I think you'd be able to do that with a change to a single file too... Donal. |
|
From: Alexandre F. <ale...@gm...> - 2008-12-14 20:11:25
|
On Sun, Dec 14, 2008 at 12:51 PM, Donal K. Fellows <don...@ma...> wrote: > >> What about special-casing the Sans, Serif and SansSerif suffixes ? > > I don't think there's a way to do it nicely. Your suggestion wouldn't > make things work any better on this system for example. Why ? The example given was FreeSans -> Freesans; so if we first retokenize "FreeSans" as "Free Sans" it does the job. -Alex |
|
From: Jan N. <jan...@gm...> - 2008-12-14 21:17:56
|
2008/12/14 Alexandre Ferrieux <ale...@gm...>:
> Why ? The example given was FreeSans -> Freesans; so if we first
> retokenize "FreeSans" as "Free Sans" it does the job.
Currently, three things are done:
1) capitalize first character of each word
2) lowercase all other characters of each word
3) remove spaces
Operation 2) is the one causing trouble. I would suggest leaving out this,
just keeping things as equal as current as possible.
This means that
"Foo Bar BooBoo tWiNkIe" -> "FooBarBoobooTwinkie"
will change to:
"Foo Bar BooBoo tWiNkIe" -> "FooBarBooBooTWiNkIe"
That's still a valid Postscript name.
At the time, postscript was invent, truetype didn't exist any more.
Nowadays, ttf fonts can used by both screens and printers, so
any valid ttf font name which can also be a valid postscript font
name (== first character capital, containing no spaces) should
be unchanged. I don't know any problems that would create.
Anyway, it is useful to create a (Tktoolkit) bug report for this,
now that TrueType fonts are more common we can expect
such kind of question more often.
I know that comp.lang.tcl is more appropriate for this question,
but in this case it's really strange behavior. I would propose
removing lines 1703 and 1704 from tkFont.c, provided no-one
comes up with an example where this causes problems. And
even if it causes a problem in some situation, that can be
solved with the -fontmap option. Food for more thought.
Regards,
Jan Nijtmans
|
|
From: Alexandre F. <ale...@gm...> - 2008-12-14 22:48:01
|
On Sun, Dec 14, 2008 at 10:17 PM, Jan Nijtmans <jan...@gm...> wrote: > > I know that comp.lang.tcl is more appropriate for this question, > but in this case it's really strange behavior. I would propose > removing lines 1703 and 1704 from tkFont.c, provided no-one > comes up with an example where this causes problems. And > even if it causes a problem in some situation, that can be > solved with the -fontmap option. Food for more thought. It sounds valid. My only worry is that this strange lowercasing has been in place since the beginning (see comments by 1.1 rjohnson). Any idea why ? -Alex |
|
From: Donal K. F. <don...@ma...> - 2008-12-14 23:06:12
|
Alexandre Ferrieux wrote: > It sounds valid. My only worry is that this strange lowercasing has > been in place since the beginning (see comments by 1.1 rjohnson). > Any idea why ? At a guess, this either was part of Tk 4.0 (as far back as I can remember there font name tricks being about) or came in with the new font system (don't remember when that happened). If memory serves, it is needed because font family names can be specified at the script level as all lower-case (common with names from XLFDs). I'm hesitant to change this code, not because I think what it does is right, but rather because I don't have any feeling at all for who and what would be affected. Forcing people to use a workaround who previously did not need to... that's a good way to get people to accuse you of breaking things unnecessarily. Donal. |
|
From: Kevin K. <ke...@ac...> - 2008-12-16 03:53:59
|
Donal K. Fellows wrote: > At a guess, this either was part of Tk 4.0 (as far back as I can > remember there font name tricks being about) or came in with the new > font system (don't remember when that happened). If memory serves, it is > needed because font family names can be specified at the script level as > all lower-case (common with names from XLFDs). > > I'm hesitant to change this code, not because I think what it does is > right, but rather because I don't have any feeling at all for who and > what would be affected. Forcing people to use a workaround who > previously did not need to... that's a good way to get people to accuse > you of breaking things unnecessarily. Arguably we missed the boat earlier, but I've long thought that we *should* have repaired the default font mapping when we upgraded the [$canvas postscript] command to do %%IncludeResource. Unfortunately, we didn't get the latter quite right, which is why font mapping is still needed - or so it appears. If I recall correctly, if I have a font in my catalog named, "Caslon Nº 224 MT" (as in fact I do)... what do I do? Tk unquestionably does not get this right, but my native system's word processor somehow manages to find CaslonTwoTwentyFour or whatever the PS font name is, and get the resources straight. That's arguably the layer we should be attacking first. If we can get that, we solve the problem for Windows, MacOSX and X11+Xft, leaving X11 without Xft the only odd man out. I'd love to have the "workaround" for the "bug" introduced by not screwing up the case in the font name be, "oh, just leave out the -fontmap, the system can figure things out correctly without it." So, in short, Donal has the right of it (don't break things gratuitously), but Jan and Alex have a deeper underlying rightness (it's mostly ok to break things that are already broken if you can fix them in the process). It's an odd system that actually still requires font mapping... except that most PostScript-generating Tk programs do, because we get things horribly wrong without it. While we're on this topic, I've another question in my ignorance. Is there an external way to resolve the %%IncludeResource directives so that I can embed fonts when it's lawful to do so? It would be really nice to be able to carry my PostScript over to a different system and have fonts like Nimbus or Andale Mono come with it. -- 73 de ke9tv/2, Kevin |
|
From: Donal K. F. <don...@ma...> - 2008-12-14 08:55:29
|
T. Horsnell wrote:
> Hi, I'm new to tcl, so apologies if this is an inappropriate list
> to ask for help.
> I have tcl/tk 8.5.2 on Fedora 9, and hav a curious problem using the
> 'postscript' command on a canvas.
Perhaps the newsgroup comp.lang.tcl would have been more appropriate,
since there are more eyes watching it.
> I have a line like:
> .c create text 200 200 -text "Hello World" -font {FreeSans 50}
> in my tcltk script file, and the text displays with the correct font.
>
> If I dump the cancas window to a file with a line like:
> .c postscript -x 0 -y 0 -height $h -width $w -pagewidth 8.0i \
> -pageheight 11.0i -pagex 4.0i -pagey 5.5i -pageanchor c \
> -file junk2.ps
> The postscript file ends up with a line like
> /Freesans findfont 50 scalefont ISOEncode setfont
>
> The FreeSans from the script has been changed to Freesans in the
> postscript file and Ghostscript cant then find the font.
>
> Short of editing all my (ttf) font files is there a fix for this?
By default, Tk's got a fairly hokey bit of font guessing code for
converting things to postscript; it's necessary to do this because
printers often have much smaller sets of fonts installed (more than just
"Times", "Helvetica" and "Courier", but not much more). As I said, the
code is hokey and is defeated by the way "FreeSans" has a significant
inner capital letter; its default of "title-case each word and
concatenate them" didn't work this time.
But there is a way round.
If you specify the -fontmap option to the postscript subcommand/method,
then you take complete control over how the font is converted since the
option lets you give your own mapping directly (well, as a name to an
array that contains the mapping). Mind you, I've not experimented with
the option a lot myself so some experimentation to get good results
might be needed. Still, at a guess this might work...
set theFont "FreeSans 50"
set mapAry($theFont) $theFont
.c postscript -fontmap mapAry ...all the other options
Of course, it should also be possible to use traces on the array to get
things working even better. Note also that postscript font names don't
have spaces in (since they're PS symbols).
More details, such as they are, are at:
http://www.tcl.tk/man/tcl8.5/TkCmd/canvas.htm#M63
The Tcler's wiki is currently very sparse on this topic. I'll add a bit
more, but you're encouraged to contribute as well.
http://wiki.tcl.tk/
As an aside for tinkering with this stuff, I found the following useful
for shortening the interactive try-a-change-and-test cycle...
less <<[.c postscript -fontmap mapAry]
Donal.
|
|
From: T. H. <ts...@mr...> - 2008-12-15 09:26:01
|
Donal K. Fellows wrote:
> T. Horsnell wrote:
>> Hi, I'm new to tcl, so apologies if this is an inappropriate list
>> to ask for help.
>> I have tcl/tk 8.5.2 on Fedora 9, and hav a curious problem using the
>> 'postscript' command on a canvas.
>
> Perhaps the newsgroup comp.lang.tcl would have been more appropriate,
> since there are more eyes watching it.
>
>> I have a line like:
>> .c create text 200 200 -text "Hello World" -font {FreeSans 50}
>> in my tcltk script file, and the text displays with the correct font.
>>
>> If I dump the cancas window to a file with a line like:
>> .c postscript -x 0 -y 0 -height $h -width $w -pagewidth 8.0i \
>> -pageheight 11.0i -pagex 4.0i -pagey 5.5i -pageanchor c \
>> -file junk2.ps
>> The postscript file ends up with a line like
>> /Freesans findfont 50 scalefont ISOEncode setfont
>>
>> The FreeSans from the script has been changed to Freesans in the
>> postscript file and Ghostscript cant then find the font.
>>
>> Short of editing all my (ttf) font files is there a fix for this?
>
> By default, Tk's got a fairly hokey bit of font guessing code for
> converting things to postscript; it's necessary to do this because
> printers often have much smaller sets of fonts installed (more than just
> "Times", "Helvetica" and "Courier", but not much more). As I said, the
> code is hokey and is defeated by the way "FreeSans" has a significant
> inner capital letter; its default of "title-case each word and
> concatenate them" didn't work this time.
>
> But there is a way round.
>
> If you specify the -fontmap option to the postscript subcommand/method,
> then you take complete control over how the font is converted since the
> option lets you give your own mapping directly (well, as a name to an
> array that contains the mapping). Mind you, I've not experimented with
> the option a lot myself so some experimentation to get good results
> might be needed. Still, at a guess this might work...
>
> set theFont "FreeSans 50"
> set mapAry($theFont) $theFont
> .c postscript -fontmap mapAry ...all the other options
>
> Of course, it should also be possible to use traces on the array to get
> things working even better. Note also that postscript font names don't
> have spaces in (since they're PS symbols).
>
> More details, such as they are, are at:
> http://www.tcl.tk/man/tcl8.5/TkCmd/canvas.htm#M63
> The Tcler's wiki is currently very sparse on this topic. I'll add a bit
> more, but you're encouraged to contribute as well.
> http://wiki.tcl.tk/
>
> As an aside for tinkering with this stuff, I found the following useful
> for shortening the interactive try-a-change-and-test cycle...
>
> less <<[.c postscript -fontmap mapAry]
>
> Donal.
A big thank-you for such rapid help.
Using the -fontmap option has fixed it.
On to the next problem, which I'll put to comp.lang.tcl as suggested.
Cheers,
Terry
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X