Re: HTML Memo does not print correctly, why?
I did some additional investigation on this HTML Memo, after which I determined I would not use this particular field type for anything. I can see why it munges the text. It does some extremely funky translation between Table and Report.
To test, I created a Browser view of the report, set to HTML so I could see the underlying HTML code that the field creates in the report. You can't see that if you do a report preview, or a PDF report on the web. What it produced on the output side is crazy.
See the images below. Image 1 is the HTML Memo source for the original record. Image 2 is one section of text in the HTML output. It's nuts - every paragraph is in its own SPAN, and every five or six words have their own FONT declaration and every space is represented as " ". There are hundreds of FONT tags in my little test, and lots of CSS for positioning, color, etc. For positioning, each paragraph has absolute positioning applied - meaning the SPAN area is being physically positioned on the space based on coordinates, not a 'natural flow' from the previous paragraph. Even the SPAN's z-index is defined. There is even a JavaScript in the output. I uploaded the output source in the attached text file.
There may be a place for this field, maybe not for text, but for positioning objects on the page. BUT it is HTML, so I would not expect it to be of any use in a report preview or any desktop application. It would be applicable to a web page or report only.
So, don't use the HTML Memo field -- find a different way to accomplish what you want. I run in to roadblocks every few days. Programming means finding an alternate solution. Maybe the HTML Memo (in concept) is required to do what you want, but there is probably something else you can do.
Work on your workaround instead. From my experience, Alpha responds in waves. Catch them at the right time and they respond instantly. They have responded to maybe half of the hundred or so bug reports I have made. I know we want 'answers' from Alpha, but again from experience, it ain't going to come until they are ready to address it, which may be never, may be tomorrow. That's not to take away from the fact that the Developer-facing part of their bug process (a consistent routine to at least let us know if something is or is not at least on a damn list, ETA for review, etc) is simply awful. To me, they more than make up for this in other areas!
I did some additional investigation on this HTML Memo, after which I determined I would not use this particular field type for anything. I can see why it munges the text. It does some extremely funky translation between Table and Report.
To test, I created a Browser view of the report, set to HTML so I could see the underlying HTML code that the field creates in the report. You can't see that if you do a report preview, or a PDF report on the web. What it produced on the output side is crazy.
See the images below. Image 1 is the HTML Memo source for the original record. Image 2 is one section of text in the HTML output. It's nuts - every paragraph is in its own SPAN, and every five or six words have their own FONT declaration and every space is represented as " ". There are hundreds of FONT tags in my little test, and lots of CSS for positioning, color, etc. For positioning, each paragraph has absolute positioning applied - meaning the SPAN area is being physically positioned on the space based on coordinates, not a 'natural flow' from the previous paragraph. Even the SPAN's z-index is defined. There is even a JavaScript in the output. I uploaded the output source in the attached text file.
There may be a place for this field, maybe not for text, but for positioning objects on the page. BUT it is HTML, so I would not expect it to be of any use in a report preview or any desktop application. It would be applicable to a web page or report only.
So, don't use the HTML Memo field -- find a different way to accomplish what you want. I run in to roadblocks every few days. Programming means finding an alternate solution. Maybe the HTML Memo (in concept) is required to do what you want, but there is probably something else you can do.
Work on your workaround instead. From my experience, Alpha responds in waves. Catch them at the right time and they respond instantly. They have responded to maybe half of the hundred or so bug reports I have made. I know we want 'answers' from Alpha, but again from experience, it ain't going to come until they are ready to address it, which may be never, may be tomorrow. That's not to take away from the fact that the Developer-facing part of their bug process (a consistent routine to at least let us know if something is or is not at least on a damn list, ETA for review, etc) is simply awful. To me, they more than make up for this in other areas!
Comment