Thread: 7.4 official docs : Fonts?
Have the fonts gone wild in the new 7.4 documentation? In the tables describing the functions and operators and in the table of contents, there are at least three different fonts of varied sizes. The usage for different types of objects seems to be fairly consistent, however, the varied sizes of the different fonts make things very hard to read. Is there anything I or someone can do to help this problem? elein
People, > of varied sizes. The usage for different types > of objects seems to be fairly consistent, > however, the varied sizes of the different fonts > make things very hard to read. Elein is correct, our variety of styles does look odd and can cause issues with readability. See, for example, http://www.postgresql.org/docs/current/static/functions-string.html Can we experiment with different SGML-to-HMTL font styles to find one that's a little easier on the eyes? What I find particularly difficult are the function parameter columns; the mix of "normal" italics with "bold" italics. Comments? Responses? -- -Josh Berkus Aglio Database Solutions San Francisco
On Wed, 2003-11-19 at 15:10, Josh Berkus wrote: > People, > > > of varied sizes. The usage for different types > > of objects seems to be fairly consistent, > > however, the varied sizes of the different fonts > > make things very hard to read. > > Elein is correct, our variety of styles does look odd and can cause issues > with readability. See, for example, > http://www.postgresql.org/docs/current/static/functions-string.html > > Can we experiment with different SGML-to-HMTL font styles to find one that's a > little easier on the eyes? What I find particularly difficult are the > function parameter columns; the mix of "normal" italics with "bold" italics. > > Comments? Responses? > Whatever we had in 7.3 we should switch back to: http://www.postgresql.org/docs/7.3/static/functions-string.html Robert Treat -- Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Josh Berkus writes: > Elein is correct, our variety of styles does look odd and can cause issues > with readability. See, for example, > http://www.postgresql.org/docs/current/static/functions-string.html > > Can we experiment with different SGML-to-HMTL font styles to find one that's a > little easier on the eyes? What I find particularly difficult are the > function parameter columns; the mix of "normal" italics with "bold" italics. Compare with the "original" version: http://developer.postgresql.org/docs/postgres/functions-string.html That looks fairly reasonable to me. So the problem appears to be in the CSS stylesheets. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut writes: > > Elein is correct, our variety of styles does look odd and can cause issues > > with readability. See, for example, > > http://www.postgresql.org/docs/current/static/functions-string.html > Compare with the "original" version: > > http://developer.postgresql.org/docs/postgres/functions-string.html > > That looks fairly reasonable to me. So the problem appears to be in the > CSS stylesheets. This page puts the discrepancies in words: http://www.postgresql.org/docs/current/static/notation.html -- Peter Eisentraut peter_e@gmx.net
On Thursday, November 20, 2003, at 05:10 AM, Josh Berkus wrote: > Can we experiment with different SGML-to-HMTL font styles to find one > that's a > little easier on the eyes? What I find particularly difficult are the > function parameter columns; the mix of "normal" italics with "bold" > italics. > > Comments? Responses? As Peter has pointed out, the CSS can handle a lot of it. It doesn't have to be hardcoded into the SGML-to-HTML transformation. One option would be to use colors as well (I'm not talking a rainbow of fruit flavors here :). In particular, I find italics often difficult to read on the web. I'll try to get a few styles worked up by tomorrow that could just be added to the css file—we can change the actual structure of the HTML later. Michael
Michael Glaesemann wrote: > > On Thursday, November 20, 2003, at 05:10 AM, Josh Berkus wrote: > > Can we experiment with different SGML-to-HMTL font styles to find one > > that's a > > little easier on the eyes? What I find particularly difficult are the > > function parameter columns; the mix of "normal" italics with "bold" > > italics. > > > > Comments? Responses? > > As Peter has pointed out, the CSS can handle a lot of it. It doesn't > have to be hardcoded into the SGML-to-HTML transformation. One option > would be to use colors as well (I'm not talking a rainbow of fruit > flavors here :). In particular, I find italics often difficult to read > on the web. I'll try to get a few styles worked up by tomorrow that I think it is the monospace italics that really look bad. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Thursday, November 20, 2003, at 12:56 PM, Bruce Momjian wrote: > Michael Glaesemann wrote: >> >> On Thursday, November 20, 2003, at 05:10 AM, Josh Berkus wrote: >>> Can we experiment with different SGML-to-HMTL font styles to find one >>> that's a >>> little easier on the eyes? What I find particularly difficult are >>> the >>> function parameter columns; the mix of "normal" italics with "bold" >>> italics. >>> >>> Comments? Responses? >> >> As Peter has pointed out, the CSS can handle a lot of it. It doesn't >> have to be hardcoded into the SGML-to-HTML transformation. One option >> would be to use colors as well (I'm not talking a rainbow of fruit >> flavors here :). In particular, I find italics often difficult to read >> on the web. I'll try to get a few styles worked up by tomorrow that > > I think it is the monospace italics that really look bad. I'd have to agree with you. Making them a color other than the text (black) or the links (blue/purple depending on your eyes) would set them off quite well. Serif fonts at small sizes can also be pretty nasty, though this isn't an issue with the PostgreSQL docs. Michael
Michael Glaesemann wrote: > >> As Peter has pointed out, the CSS can handle a lot of it. It doesn't > >> have to be hardcoded into the SGML-to-HTML transformation. One option > >> would be to use colors as well (I'm not talking a rainbow of fruit > >> flavors here :). In particular, I find italics often difficult to read > >> on the web. I'll try to get a few styles worked up by tomorrow that > > > > I think it is the monospace italics that really look bad. > > I'd have to agree with you. Making them a color other than the text > (black) or the links (blue/purple depending on your eyes) would set > them off quite well. Serif fonts at small sizes can also be pretty > nasty, though this isn't an issue with the PostgreSQL docs. If we go with color, making them printable on a non-color printer becomes a problem. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Friday, November 21, 2003, at 01:36 AM, Bruce Momjian wrote: > Michael Glaesemann wrote: >>>> As Peter has pointed out, the CSS can handle a lot of it. It doesn't >>>> have to be hardcoded into the SGML-to-HTML transformation. One >>>> option >>>> would be to use colors as well (I'm not talking a rainbow of fruit >>>> flavors here :). In particular, I find italics often difficult to >>>> read >>>> on the web. I'll try to get a few styles worked up by tomorrow that >>> >>> I think it is the monospace italics that really look bad. >> >> I'd have to agree with you. Making them a color other than the text >> (black) or the links (blue/purple depending on your eyes) would set >> them off quite well. Serif fonts at small sizes can also be pretty >> nasty, though this isn't an issue with the PostgreSQL docs. > > If we go with color, making them printable on a non-color printer > becomes a problem. Good point. A way to handle this is to use an additional style sheet for media="print" that distinguishes between the keywords/parameters/functions in a different way. If we make any changes to how syntax is represented, the conventions page will need to be rewritten, and an option would be to rewrite it in a way that does not explicitly spell out the differences (e.g., "italics ( example ) indicate placeholders; "), but rather present a table or an example showing the different parts. This way the style sheets will always be in congruence with the notation explanation. Just an idea. I think it's good to have some redundancy in distinguishing these things. Not only for those without color printers (poor souls ;) but also for people who have trouble distinguishing color differences. When I was experimenting with different color schemes, I thought about perhaps matching the syntax coloring of my editor, BBEdit. However, I'm sure not all editors use the same color scheme (the ANSI SQL language module for BBEdit displays only blue (keywords), pink (strings), and black (everything else). The blue would conflict with the current link color, and I'd rather not use pink unless everyone else thinks it's a good idea.) I'm interested in hearing what editors others use for coding, and what syntax coloring schemes they use for SQL. Michael
Michael Glaesemann wrote: > When I was experimenting with different color schemes, I thought about > perhaps matching the syntax coloring of my editor, BBEdit. However, I'm > sure not all editors use the same color scheme (the ANSI SQL language > module for BBEdit displays only blue (keywords), pink (strings), and > black (everything else). The blue would conflict with the current link > color, and I'd rather not use pink unless everyone else thinks it's a > good idea.) I'm interested in hearing what editors others use for > coding, and what syntax coloring schemes they use for SQL. Yes, colorizing editors really help me understand the code. I use Crisp, which is a commercial editor. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Thu, Nov 20, 2003 at 12:16:58PM -0500, Bruce Momjian wrote: > Michael Glaesemann wrote: > > When I was experimenting with different color schemes, I thought about > > perhaps matching the syntax coloring of my editor, BBEdit. However, I'm > > sure not all editors use the same color scheme (the ANSI SQL language > > module for BBEdit displays only blue (keywords), pink (strings), and > > black (everything else). The blue would conflict with the current link > > color, and I'd rather not use pink unless everyone else thinks it's a > > good idea.) I'm interested in hearing what editors others use for > > coding, and what syntax coloring schemes they use for SQL. I use vim, it has good SQL coloring syntax. The one problem that I'd like to fix in it is that the body of PL/pgSQL functions are shown as a big string. -Roberto -- +----| Roberto Mello - http://www.brasileiro.net/ |------+ + Computer Science Graduate Student, Utah State University + + USU Free Software & GNU/Linux Club - http://fslc.usu.edu/ + YES!! eh, NO!!! oh, well MAYBE!!!!!!!!
On Friday, November 21, 2003, at 02:31 AM, Roberto Mello wrote: > On Thu, Nov 20, 2003 at 12:16:58PM -0500, Bruce Momjian wrote: >> Michael Glaesemann wrote: >>> When I was experimenting with different color schemes, I thought >>> about >>> perhaps matching the syntax coloring of my editor, BBEdit. However, >>> I'm >>> sure not all editors use the same color scheme (the ANSI SQL language >>> module for BBEdit displays only blue (keywords), pink (strings), and >>> black (everything else). The blue would conflict with the current >>> link >>> color, and I'd rather not use pink unless everyone else thinks it's a >>> good idea.) I'm interested in hearing what editors others use for >>> coding, and what syntax coloring schemes they use for SQL. > > I use vim, it has good SQL coloring syntax. The one problem that I'd > like > to fix in it is that the body of PL/pgSQL functions are shown as a big > string. I know what you mean. Same thing in BBEdit. Really, that's what they are, but it'd be nice if there were some way of distinguishing the parts of the strings. One of the issues is that (at least for BBEdit) the SQL syntax coloring is based on ANSI SQL, not PostgreSQL. I'd like to hack my own language module for this, but haven't got around to doing it. On Friday, November 21, 2003, at 02:16 AM, Bruce Momjian wrote: > Yes, colorizing editors really help me understand the code. I use > Crisp, which is a commercial editor. Visiting the CRiSP site, I see they have a Mac version for demo. I'll give it a whirl, and see what their colors are like. Michael
Michael Glaesemann <grzm@myrealbox.com> writes:
> Just an idea. I think it's good to have some redundancy in
> distinguishing these things. Not only for those without color printers
> (poor souls ;) but also for people who have trouble distinguishing
> color differences.
Yes. I don't have an objection to using color, but it has to be in
addition to a font difference, not a substitute for a font difference.
regards, tom lane
Guys, > > > color, and I'd rather not use pink unless everyone else thinks it's a > > > good idea.) Nooooo! pink on white == totally illegible > I use vim, it has good SQL coloring syntax. The one problem that I'd like > to fix in it is that the body of PL/pgSQL functions are shown as a big > string. Yeah. In Kate (with the PostgreSQL plug-in) I frequently wait until I'm done writing the procedure to quote it. What we could really use is a postgresql function editor with syntax highlighting, perhaps as a bonus to pgAdmin or pgAccess. -- Josh Berkus Aglio Database Solutions San Francisco
On Friday, November 21, 2003, at 02:49 AM, Josh Berkus wrote: > Guys, > >>>> color, and I'd rather not use pink unless everyone else thinks it's >>>> a >>>> good idea.) Yes, Josh, I *am* your father. > Nooooo! (Sorry ;) > pink on white == totally illegible Tell me about it! (Guess I could just make a little trip to preferences to change it...) > Yeah. In Kate (with the PostgreSQL plug-in) I frequently wait until > I'm done > writing the procedure to quote it. Nice to hear there are PostgreSQL-specific plug-ins out there. I assume it picks up the additional PostgreSQL keywords?
Le Jeudi 20 Novembre 2003 16:36, Bruce Momjian a écrit :
> Michael Glaesemann wrote:
> > >> As Peter has pointed out, the CSS can handle a lot of it. It doesn't
> > >> have to be hardcoded into the SGML-to-HTML transformation. One option
> > >> would be to use colors as well (I'm not talking a rainbow of fruit
> > >> flavors here :). In particular, I find italics often difficult to read
> > >> on the web. I'll try to get a few styles worked up by tomorrow that
> > >
> > > I think it is the monospace italics that really look bad.
> >
> > I'd have to agree with you. Making them a color other than the text
> > (black) or the links (blue/purple depending on your eyes) would set
> > them off quite well. Serif fonts at small sizes can also be pretty
> > nasty, though this isn't an issue with the PostgreSQL docs.
>
> If we go with color, making them printable on a non-color printer
> becomes a problem.
This is not totaly true.
You can have alternate stylesheets depending on the media : on colorized for
screen, one black and white for printer. Latest releases of current browers
(mozilla, ie6) are able to handle these tags :
<link rel="stylesheet" type="text/css" href="2columnspg.css" media="screen"
title="TwoColumn">
<link rel="stylesheet" type="text/css" href="printpg.css" media="print">
Adding a title make them available for stylesheet switching in the browser
(mozilla).
--
Guillaume
<!-- http://absfr.tuxfamily.org/
http://pgsql-fr.tuxfamily.org/ -->.
[sNip] >> http://www.postgresql.org/docs/current/static/functions-string.html [sNip] > Whatever we had in 7.3 we should switch back to: > > http://www.postgresql.org/docs/7.3/static/functions-string.html I think the fancy fonts should be abandonded altogether in favour of using the web browser's default fonts. In Opera, the text on both of those page (quoted above) are difficult to read because the choice of font is horrible. -- Randolf Richardson - rr@8x.ca Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.8x.ca/ This message originated from within a secure, reliable, high-performance network ... a Novell NetWare network.
It is *much* more important to have legible black and white text than it is to introduce colors. Don't run off track with the colors--it would be a bonus extra. Also, wrt colors, it is important to choose colors in a way that handle color blindness. I had a great URL on this that I can't find right now, but the topic is google-able. Also, especially since not everyone sees the same colors, you will *never* agree on syntax colors. (That is why I inevitably edit my vim syntax files.) --elein On Thu, Nov 20, 2003 at 07:14:53PM +0000, Guillaume LELARGE wrote: > Le Jeudi 20 Novembre 2003 16:36, Bruce Momjian a écrit : > > Michael Glaesemann wrote: > > > >> As Peter has pointed out, the CSS can handle a lot of it. It doesn't > > > >> have to be hardcoded into the SGML-to-HTML transformation. One option > > > >> would be to use colors as well (I'm not talking a rainbow of fruit > > > >> flavors here :). In particular, I find italics often difficult to read > > > >> on the web. I'll try to get a few styles worked up by tomorrow that > > > > > > > > I think it is the monospace italics that really look bad. > > > > > > I'd have to agree with you. Making them a color other than the text > > > (black) or the links (blue/purple depending on your eyes) would set > > > them off quite well. Serif fonts at small sizes can also be pretty > > > nasty, though this isn't an issue with the PostgreSQL docs. > > > > If we go with color, making them printable on a non-color printer > > becomes a problem. > This is not totaly true. > > You can have alternate stylesheets depending on the media : on colorized for > screen, one black and white for printer. Latest releases of current browers > (mozilla, ie6) are able to handle these tags : > <link rel="stylesheet" type="text/css" href="2columnspg.css" media="screen" > title="TwoColumn"> > <link rel="stylesheet" type="text/css" href="printpg.css" media="print"> > > Adding a title make them available for stylesheet switching in the browser > (mozilla). > > > -- > Guillaume > <!-- http://absfr.tuxfamily.org/ > http://pgsql-fr.tuxfamily.org/ -->. > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match
At 2:11 PM +0900 11/20/03, Michael Glaesemann wrote: >On Thursday, November 20, 2003, at 12:56 PM, Bruce Momjian wrote: > >>Michael Glaesemann wrote: >>> >>>On Thursday, November 20, 2003, at 05:10 AM, Josh Berkus wrote: >>>>Can we experiment with different SGML-to-HMTL font styles to find one >>>>that's a >>>>little easier on the eyes? What I find particularly difficult are the >>>>function parameter columns; the mix of "normal" italics with "bold" >>>>italics. >>>> >>>>Comments? Responses? >>> >>>As Peter has pointed out, the CSS can handle a lot of it. It doesn't >>>have to be hardcoded into the SGML-to-HTML transformation. One option >>>would be to use colors as well (I'm not talking a rainbow of fruit >>>flavors here :). In particular, I find italics often difficult to read >>>on the web. I'll try to get a few styles worked up by tomorrow that >> >>I think it is the monospace italics that really look bad. > >I'd have to agree with you. Making them a color other than the text >(black) or the links (blue/purple depending on your eyes) would set >them off quite well. Serif fonts at small sizes can also be pretty >nasty, though this isn't an issue with the PostgreSQL docs. Color works well on-screen with html. Small-point-size italics are hard to read on-screen, agreed. Italics work well on B&W printout with PDF. (In general. I'm not looking at the specific example.) Can you map things somehow to get the best of both worlds? -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
On Friday, November 28, 2003, at 05:33 PM, Henry B. Hotz wrote: > Color works well on-screen with html. Small-point-size italics are > hard to read on-screen, agreed. > > Italics work well on B&W printout with PDF. (In general. I'm not > looking at the specific example.) > > Can you map things somehow to get the best of both worlds? If you're talking about printing from the browser, you can have separate style sheets with different media targets, so media="screen" could have the color, while media="print" could have italics. It's really flexible. At work I have a form letter that's generated on screen, and includes all of the navigation for moving around the site. When you print the page, the media="print" style sheet omits the navigation, restyles the page with different fonts and sizes, and adds the number we want to fax it to (Yes, I know. We still use fax for a large part of our interoffice correspondence. I'm trying to move us away from that, but it's a hard slog.) As for the PDF docs, they're formatting is indeed different. I assume that the SGML to PDF path is different from the SGML to HTML path (which is of course one of the benefits of using SGML). Is this what you mean? Michael
At 7:30 PM +0900 11/28/03, Michael Glaesemann wrote: >On Friday, November 28, 2003, at 05:33 PM, Henry B. Hotz wrote: > >>Color works well on-screen with html. Small-point-size italics are >>hard to read on-screen, agreed. >> >>Italics work well on B&W printout with PDF. (In general. I'm not >>looking at the specific example.) >> >>Can you map things somehow to get the best of both worlds? > >If you're talking about printing from the browser, you can have >separate style sheets with different media targets, so >media="screen" could have the color, while media="print" could have >italics. It's really flexible. At work I have a form letter that's >generated on screen, and includes all of the navigation for moving >around the site. When you print the page, the media="print" style >sheet omits the navigation, restyles the page with different fonts >and sizes, and adds the number we want to fax it to (Yes, I know. We >still use fax for a large part of our interoffice correspondence. >I'm trying to move us away from that, but it's a hard slog.) > >As for the PDF docs, they're formatting is indeed different. I >assume that the SGML to PDF path is different from the SGML to HTML >path (which is of course one of the benefits of using SGML). > >Is this what you mean? Pretty much, yes. I don't care much about printing html. If I want to print I figure I'm better off getting a PDF. I just don't want to have to use a color printer. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
[sNip]
> Pretty much, yes. I don't care much about printing html. If I want
> to print I figure I'm better off getting a PDF.
I prefer to print from PDF also because the formatting is always
perfect. Unfortunately this just hasn't been the case with any other format,
including HTML, WordPerfect (and those horrid Microsoft Word) documents, and
even plain old text files.
At least with PDF this problem has been solved.
> I just don't want to have to use a color printer.
When I'm reading large amounts of text on paper, black text is my
preference because so many people just pick the wrong colours (and pretty
much everyone has different tastes and expectations in this regard).
--
Randolf Richardson - rr@8x.ca
Vancouver, British Columbia, Canada
Please do not eMail me directly when responding
to my postings in the newsgroups.