Alaska Software Inc. - Bug: HRF alters HTML output compared to original...
Username: Password:
AuthorTopic: Bug: HRF alters HTML output compared to original...
Thomas BraunBug: HRF alters HTML output compared to original...
on Tue, 21 Apr 2015 13:43:35 +0200
Hi,

this is a very old problem - it is present since HRF exists.

I'm not sure if this can be fixed at all.

Consider the following HTML markup (test.htm):

<html>
  <body>
   <p>4<sup>th</sup> to 7<sup>th</sup></th> October</p>
  </body>
</html>


Now use the following code to create some HTML output:

FUNCTION HRFTest()
LOCAL oDoc, cText

   oDoc  := HTMLDocument():New():LoadFile(".\test.htm")

   oDoc:SaveFile(".\test2.htm", 3, CHR(13)+CHR(10))
   oDoc:SaveFile(".\test3.htm", 0, "")

RETURN NIL

This results in the following browser display - pay attention to the spaces
in the date:

4th to 7th October (test.htm = correct original)
4 th to 7 th October (test2.htm)
4thto 7thOctober (test3.htm)

There seems to be no way to preserve the original layout - either there are
spaces where no spaces should be or spaces that exist in the original file
are removed.

This is also a problem when creating email markup like this:

<p>Dear <span id="salutation"></span><span id="lastname"></span>,</p>

Which for example results in 

   Dear Mr. Miller , 
                  ^
(A space before the comma is inserted which does not belong there and looks
ugly)

Probably the only real way to fix this would be to use &nbsp; where needed.

Thomas
Till WarwegRe: Bug: HRF alters HTML output compared to original...
on Thu, 07 May 2015 12:17:38 +0200
Dear Thomas, 

  You're right, the HRF seems to inadvertendly insert spaces 
when streaming HTML containing block tags such <p> which 
have child elements. As you said, this seems to be due to the 
formatting which is applied by the HRF. I've opened PDR
6643 for this issue.

Regards,
  Till Warweg
  [Alaska Software]

--------------------------------------------------------------------
Technical Support:         support@alaska-software.com
News Server:                 news.alaska-software.com
Homepage:                     http://www.alaska-software.com
KnowledgeBase:            http://www.alaska-software.com/kb
--------------------------------------------------------------------



"Thomas Braun" schrieb im Newsbeitrag news:13372b7vbsq2$.1koa3bx1x34gy.dlg@40tude.net...
> Hi,
> 
> this is a very old problem - it is present since HRF exists.
> 
> I'm not sure if this *can* be fixed at all.
> 
> Consider the following HTML markup (test.htm):
> 
> <html>
>  <body>
>   <p>4<sup>th</sup> to 7<sup>th</sup></th> October</p>
>  </body>
> </html>
> 
> 
> Now use the following code to create some HTML output:
> 
> FUNCTION HRFTest()
> LOCAL oDoc, cText
> 
>   oDoc  := HTMLDocument():New():LoadFile(".\test.htm")
> 
>   oDoc:SaveFile(".\test2.htm", 3, CHR(13)+CHR(10))
>   oDoc:SaveFile(".\test3.htm", 0, "")
> 
> RETURN NIL
> 
> This results in the following browser display - pay attention to the spaces
> in the date:
> 
> 4th to 7th October (test.htm = correct original)
> 4 th to 7 th October (test2.htm)
> 4thto 7thOctober (test3.htm)
> 
> There seems to be no way to preserve the original layout - either there are
> spaces where no spaces should be or spaces that exist in the original file
> are removed.
> 
> This is also a problem when creating email markup like this:
> 
> <p>Dear <span id="salutation"></span><span id="lastname"></span>,</p>
> 
> Which for example results in 
> 
>   Dear Mr. Miller , 
>                  ^
> (A space before the comma is inserted which does not belong there and looks
> ugly)
> 
> Probably the only real way to fix this would be to use &nbsp; where needed.
> 
> Thomas
Thomas BraunRe: Bug: HRF alters HTML output compared to original...
on Fri, 08 May 2015 09:08:10 +0200
Till Warweg wrote:

>   You're right, the HRF seems to inadvertendly insert spaces 
> when streaming HTML containing block tags such <p> which 
> have child elements. As you said, this seems to be due to the 
> formatting which is applied by the HRF. I've opened PDR
> 6643 for this issue.

Hi Till,

thanks for confirming this and opening a PDR 

Thomas