Hi,

http://bugs.freepascal.org/view.php?id=17542

I reported this bug, because only recently did HTML output start being double spaced (extra blank lines between lists of used units, Class/Type definition etc).

As I said in the bug report, there was no such problems with HTML output until recently. Firefox, Netscape, IE, Chrome etc all show the same problem, so it's NOT a browser thing or CSS file issue. My CSS hasn't changed in years (neither has CCR-Lazarus), I always use the same script to generate the HTML output. Yet the tiOPF, LCL, fpGUI, RTL etc class docs in HTML format now suddenly have double spacing in the output. Even the CCR-Lazarus site shows the problem.

@Marco,
If you don't know what is causing the bug or don't know how to fix it, simply say so and move on. But keep arguing that there is no bug, and simply marking the bug report as resolved is not the answer! I have clearly shown to you the difference between the old fpdoc (June 2009) and latest fpdoc. Something changed and the new output looks crap.

Regards,
- Graeme -

Marco didn't close the bug. I did.

Please note that I set it to 'Unable to reproduce'.

You can re-open the bug report if you can reliably show that the doc generation fails.

If you can show that it consistently behaves a certain way, then we can track and solve the problem, I have no problem with that. But until now you're the only one that has the problem in a certain case, and you have been unable to show that the problem indeed lies with FPC, which leads me to conclude that the problem lies on your machine or copy of fpdoc.css, rather than in the fpdoc system.

The officially generated docs on the website do not have the problem. They are generated with the latest fpdoc and fpdoc.css. I tested it with 2 browsers.

Note also that to my knowledge, the algorithm for generation of HTML or fpdoc.css have not been changed for at least 5 years. If you can pinpoint the revision where the problem occurs, this is fine too.

Hence 'unable to reproduce', and not "won't fix"...

Michael.

Op 2010-11-08 10:11, Michael Van Canneyt het geskryf:

Marco didn't close the bug. I did.

Apologies to Marco then.

If you read the bug report in detail, I did list all of this, I also listed other documentation (not under my control) that shows the same problem. So I ruled out a problem with my setup (which also hasn't changed for years).

If you want another example (not under my control and not generated by me):

Working:
http://www.freepascal.org/docs-html/rtl/index.html

Not Working:
http://lazarus-ccr.sourceforge.net/docs/rtl/index.html http://lazarus-ccr.sourceforge.net/docs/lcl/index.html http://lazarus-ccr.sourceforge.net/docs/fcl/index.html (see the double spacing in the list of units)

To reproduce, all I have to do is run the tiOPF or fpGUI's fpdoc scripts that generate HTML output. No trickery required. And again, these scripts (especially the tiOPF one) hasn't changed in years, yet the output generated June 2009 (which is currently available online) is *not* the same as the output it generates now with the latest fpdoc. So the only thing that has changed between June 2009 and now is fpdoc. Nothing changed in my scripts and nothing changed in my fpdoc.css style file.

Regards,
- Graeme -

---------- Forwarded message ----------

If you look at the first website, the docs are generated march 6, 2010, not in 2009.

is *not* the same as the output it generates now with the latest fpdoc. So the only thing that has changed between June 2009 and now is fpdoc. Nothing changed in my scripts and nothing changed in my fpdoc.css style file.

If you have a look at the fpdoc.css (as I did now) then you'll see that the fpdoc.csse used on the FPC website is different from the one on the Lazarus site.

The one on the FPC website is the 'official' one. Where the other one comes from, I don't know (yet).

At least, now we have a basis for testing. I will investigate.

Michael.

You came to the same conclusion as I, let's now see where the lazarus copy comes from, and what css rule causes the change.

Michael.

Ah.

Graeme, can you please confirm this ?

Michael.

Op 2010-11-08 10:11, Michael Van Canneyt het geskryf:

The officially generated docs on the website do not have the problem. They are generated with the latest fpdoc and fpdoc.css. I tested it with 2 browsers.

As done before I reported the bug, I did it now (again). I copied the fpdoc.css from the official Documenation FPC website and copied it over what I have locally in my tiOPF generated HTML class docs.

http://www.freepascal.org/docs-html/rtl/fpdoc.css

I then viewed the HTML files on my local system using Firefox 3.5 and 4.0(beta) and _still_ the double spacing exists. So again, NO it is not a .css file issue. I did a diff between my copy of fpdoc.css and what is on the official FPC docs website. The only change was a comment in the first line, and a font size setting for various tags to use a 14px font instead of the web browser default size.

BTW:
My fpdoc.css file was last modified in 2005. It as a reference in the top line that it was modified by Vincent, so it must have been a copy I got from the Lazarus project.

Regards,
- Graeme -

Op 2010-11-08 10:43, Amat Coder het geskryf:

td p { margin: 0; }

The official FPC docs fpdoc.css doesn't have that in the css file, yet it outputs correctly.

http://www.freepascal.org/docs-html/rtl/fpdoc.css

It is easy to "force" a fix via a CSS file, but clearly there is a HTML generation problem/difference since June 2009. Even the plain HTML output (without a css file) is different between now and a year ago.

Regards,
- Graeme -

That's because there are some other things different as well if you look carefully.

It is easy to "force" a fix via a CSS file, but clearly there is a HTML generation problem/difference since June 2009. Even the plain HTML output (without a css file) is different between now and a year ago.

How so ?

Below is a diff of the lazarus and fpc HTML pages. With the exception of some header and an extra unit, the geneated HTML code is the same. The footer is added by sourceforge.

Like I said, the HTML generation algorithm has not changed. The css has, and this causes your problem. If you use the official fpdoc.css from FPC, the problem will go away.

Michael.

-------------------------------------------------------------------

1c1
< <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> ---

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

210a211,215

252,254c257,261
< <hr>
<
< <span class="footer">Documentation generated on: Mar 06 2010</span> ---

Op 2010-11-08 10:49, Michael Van Canneyt het geskryf:

If you look at the first website, the docs are generated march 6, 2010, not in 2009.

My reference to June 2009, is the last time I generate tiOPF docs on my server. The problem came to my attention when I recently wanted to update the tiOPF online help, but immediately noticed the doublespace issue.

http://opensoft.homeip.net:8080/tiopf/core/index.html

If you have a look at the fpdoc.css (as I did now) then you'll see that the fpdoc.csse used on the FPC website is different from the one on the Lazarus site.

And here is the difference between the Official FPC Docs fpdoc.css and what I have locally. As you can see, my copy in near identical to the official fpc one, I simply define a specific font size. But as I said, even if I used the offcial fpdoc.css file, I still have double spacing. So again, the issue is _not_ related to the CSS file, but to the actual HTML generated. This is easily seen, by simply disabling CSS in your browser. With Firefox do the following "View - Page Style - No Style" Correct HTML shows no double spacing. Incorrect HTML (as I have here) shows double spacing (even with CSS disabled).

If it will help, I can put the "broken" tiOPF docs up on my server too, in a temp directory.

---------------------------------------------------- $ diff -u -w core/fpdoc.css gui/fpdoc.css
--- core/fpdoc.css 2010-11-08 11:03:08.000000000 +0200 +++ gui/fpdoc.css 2009-05-28 09:26:29.000000000 +0200 @@ -1,5 +1,5 @@
/*
- $Id: fpdoc.css,v 1.4 2001/09/08 12:08:32 sg Exp $
+ $Id: fpdoc.css 7437 2005-07-28 16:02:24 +0200 (Thu, 28 Jul 2005) vincents $

Default style sheet for FPDoc reference documentation by Sebastian Guenther,
@@ -17,7 +17,11 @@
}

tt, span.kw, pre {
- font-family: Courier, monospace
+ font-family: monospace, Courier
+}
+
+body, p, th, td, caption, ul, ol, dl, tt, span.kw, pre {
+ font-size: 14px
}

A:link {
----------------------------------------------------

Regards,
- Graeme -

Op 2010-11-08 11:03, Michael Van Canneyt het geskryf:

With CSS you can manipulate any HTML output to suite your design. So using CSS to "fake a solution" is not correct. Because what if you remove fpdoc.ss completely, then you still see the double spacing, yet in older fpdoc versions there was no double spacing.

Like I said, the HTML generation algorithm has not changed. The css has, and this causes your problem. If you use the official fpdoc.css from FPC, the problem will go away.

The first thing I tried (and just did so again), and NO it doesn't fix the problem here.

Of course the HTML output generation has changed. New support for Interfaces, improved parent class listing, improved class hierarchy output, and that is just the ones I can remember without looking at the repository history.

Regards,
- Graeme -

Of course, that's what CSS is for, to specify how the browser must render the HTML.

Did you refresh your browser's cache ?
(question number 1 of the helpdesk when experiencing HTML problems)

Of course the HTML output generation has changed. New support for Interfaces, improved parent class listing, improved class hierarchy output, and that is just the ones I can remember without looking at the repository history.

That is just more HTML being generated, not the way HTML is generated, and thus beside the point.

Graeme,

Did you actually look at the diff I sent for the 2 pages which are displayed differently ?

1. You sent me the links for 2 pages that look different.
2. I confirm they are looking different in the browser.
3. Then I downloaded both pages with wget.
4. I made a diff.
5. I pasted the diff in my mail.

As you can see from the diff, the generated HTML is 100% the same for the part that looks different. The ONLY difference is in the CSS and the HTML doctype tag.

If you claim that different HTML is being generated *for the same information*, then please demonstrate it with a proper diff that proves your point.

Michael.

Graeme wrote

...Because what if you remove fpdoc.ss completely, then you still see the double spacing, yet in older fpdoc versions there was no double spacing...

You can do that:
Edit html and delete "http://www.w3.org/TR/html4/loose.dtd" from first line

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " http://www.w3.org/TR/html4/loose.dtd">

and even if you don't use any css you can see that no double spacing.

This is because 'dtd' forces some elements if they are not defined...

Dtd declaration was introduced on May,30 2010 with revision 15345.

Please see
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=15345

Regards.

Fine.

Let's remember you learned something new today.
One is never too old to learn.

Michael.

Op 2010-11-08 11:03, Michael Van Canneyt het geskryf:

Below is a diff of the lazarus and fpc HTML pages. With the exception of some header and an extra unit, the geneated HTML code is the same. The footer is added by sourceforge.

This gave me an idea and I found the difference, and what causes the problem. As suspected, it has nothing todo with the CSS file. And you were indeed correct, that the general HTML output did not changed. One thing that did however change is shown below.

-----------------------------------------------
$ diff -u -w index.html /home/graemeg/programming/3rdParty/tiOPF2/Docs/html/core/index.html --- index.html 2010-11-08 11:25:50.000000000 +0200 +++ /home/graemeg/programming/3rdParty/tiOPF2/Docs/html/core/index.html 2010-11-08 11:25:24.000000000 +0200 @@ -1,4 +1,4 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">

-----------------------------------------------

The first file is the one I currently have online for tiOPF. The second file is the newly generated file. The only difference is the version of the HTML, from 4.0 to 4.01. If I copy the old DOCTYPE line over the new one, then the new one displays correctly in Chrome, Firefox etc... no need to touch the fpdoc.css file or anything else for that matter.

I had no idea the DOCTYPE could do that in web browsers. The reason I never picked that up before, was because I kept comparing HTML pages of classes, and the documentation changed to much between old and new so I couldn't easily see what changed. I then looked for a file that did not really change (irrespective of new class documentation that was added since). Then I spotted the difference.

Well, seeing that it isn't really a bug in fpdoc (well not a obvious HTML generation bug as I first suspected), I guess the only simple fix is then to use Amat idea of forcing the look we want with a tweak to the CSS file. At this point I can't be bothered to go read up on the various DTD files and how they differ between versions. I already waisted way to much of my time on this issue.

Regards,
- Graeme -

Op 2010-11-08 11:31, Amat Coder het geskryf:

This was indeed the cause of the problem.
I don't know HTML well enough to know what all the stuff in DTD files mean or do, but I gather having it listed in the generated HTML is important? If so, I take you word on it, and will simply apply your css fix to work around the issue.

Regards,
- Graeme -

It gets only really interesting when you start comparing how browsers react on this DTD reference. In theory, they should react the same. Practice shows different...

Michael.

Graeme wrote

I don't know HTML well enough to know what all the stuff in DTD files mean or do, but I gather having it listed in the generated HTML is important?

Well, DTD is one W3C recommendation, specifies the rules for correct rendering
for all browsers. Standards are important, so I think that DTD declaration should be
left.

Regards.

Op 2010-11-08 11:48, Michael Van Canneyt het geskryf:

It gets only really interesting when you start comparing how browsers react on this DTD reference. In theory, they should react the same. Practice shows different...

And that's why I stay away from web apps and web development. I like consistency too much, so give me desktop or console apps any time of the time.

Regards,
- Graeme -

My ideas exactly. But the market thinks otherwise:

Currently I've pulled out half my hair, because my web app works perfect and extremely fast in Firefox, Google Chrome and Safari, but not in M$ IE.

Since our clients often use IE (Yes, flanders is a backward country in some ways), that puts me in a difficult position, because debugging Javascript in IE is next to impossible. You don't have half the possibilities that one has in Firefox, plus it works sloooooowww to boot...

(and then I didn't even mention that we must support all IE versions, including the much-dreaded version 6.)

A nuclear missile aimed and fired at Redmond HQ would of course solve many problems (unless it runs MS software, in which case it probably ends up in finland somewhere).

Ah well, the life of a developer... Keeps us off the streets, presumably.

Michael.

Hello FPC,

you wrote

>I don't know HTML well enough to know what all the stuff in DTD files mean >or do, but I gather having it listed in the generated HTML is important?

AC> Well, DTD is one W3C recommendation, specifies the rules for correct AC> rendering
AC> for all browsers. Standards are important, so I think that DTD declaration AC> should be
AC> left.

The "double" lines effect is due the presence of <p> tags in table cells. A <p> tag implies a carriage return so changing <p> tag by a <span> tag "solves" the double line effect. I do not know if <p> tag is mandatory somehow in the generated tables :-?

The different output problem exists in either case, when every application can use a different widget or widgetset, or read config files from many different locations. The more settings - the more problem sources :-(

DoDi

Op 2010-11-08 18:55, Hans-Peter Diettrich het geskryf:

The different output problem exists in either case, when every application can use a different widget or widgetset, or read config files from many different locations.

I was actually referring to software I create. Whatever desktop applications I create, I use fpGUI. And with that I have consistent look and behaviour on all platforms - solving the problem compared to web apps.

Regards,
- Graeme -