Document tab in draft display unnecessarily too narrow on Android/Firefox #2241
Comments
|
@[email protected] commented At the moment, I'm leaning towards removing the header and tabs completely, and re-using almost all of the styling from the tools.ietf.org/html/ . Does that layout and styling work on your devices? Best regards, |
|
@[email protected] commented Yes, the tools.ietf.org/html formatting seems to work just fine on Android/Firefox combination in landscape and portrait modes both in full and split/half screen formats on the Tab S2 9.7 inch screen. In all cases it seems to display the full width of text with appropriate font sizes. It has worked well on Windows for many years (no problems I have noticed). I'll see what it looks like on an Android smartphone with a small screen tomorrow. Cheers, |
|
@[email protected] commented As promised, I checked it out on an Android smartphone also running 6.0.1. The tools.ietf.org/html style formatting works well there as well. Ab initio the text is a bit, no a lot, small (but readable for those with decent eyesight). I tried it with Chrome rather than Firefox. There you have the choice of zooming in and panning back and forth (which also works with Firefox) or using the 'mobile friendly' display that wraps the long lines in a pop-up window. Either way it would certainly be an acceptable way of reading RFCs and drafts for me. I don't have the technology to check out Apple devices. Would it be sensible to remove the 'alternative formats' buttons on the status page as the tools.ietf.org/html format gives access to txt and pdf etc. Then one could either:
Ensuring that the generated xml2rfc reference anchor matches the one used in the xml2rfc bibliography databases kills two birds with one stone: one could either cut and paste the whole thing or just the anchor for importing etc. |
|
@[email protected] changed _comment0 which not transferred by tractive |
|
@[email protected] changed priority from |
|
@[email protected] changed status from |
|
@[email protected] changed resolution from `` to |
|
@[email protected] commented Fixed in a9b259e: Changed the message shown when xml file parsing fails during draft submission to include the actual error message from the xml parser. Fixes issue #2241. |
|
@[email protected] commented The fix has much improved matters. One aesthetic quibble: In half screen mode on Android, there is no white space at all to the right of the text when the column width is not sufficient to display the whole width of the text. There is a roughly one character left margin so the display is not symmetrical. Not sure if anything could be done about this, but it is not a big deal. |
resolution_fixedtype_defect| by [email protected]The (new) document tab on the draft display page appears to use too narrow a column for the document text when used in the Firefox browser (52.0.1) on Android (6.0.1) even though there is more than enough screen width to display the whole line length. (This was the symptom that provoked the report in the first place. Turns out it is more complicated and is of more general relevance by the looks of it).
I am working on a Samsung Galaxy Tab S2 with a 9.7 inch screen in landscape mode. By default with the browser window occupying the whole screen, the dcoument display tab is approx 165mm wide with the remaining 30mm of screen width occupied by the menu pane. The header for the document text display is fully visible showing versions and document track: It is 120mm wide and offset 35mm from the menu pane. However the actual text is displayed in a narrower, 100mm wide column. This means that right hand 9 characters of the text are hidden but can be seen by moving the page contents leftwards with mouse or finger drag. The ability to do this on a per page basis is an interesting conceit!
Given that the whole header is visible and it is the same width as the complete 72 character wide text, this would seem to be a layout bug - it should be possible to display the complete text. The calculation seems to allow about 30mm of empty screen space to the left of the text viewport and centre the viewport so that there is also 30mm of empty screen space to the right of the viewport. Things would work better, I think, if the header and viewport were kept the same width and centred in the available space.
On Windows(8.1) also with Firefox (52.0.1) the document pages display nicely in a 72 character wide per page viewport while the browser window is relatively wide - on my screen the header occupies 170mm and provided there is 110 mm of additional space (55mm on either side of the text viewport, the whole 72 characters of the document text are displayed. As postulated above this means that header and viewport are at this point centred in the available space to the right of the menu pane.
As the window width is reduced so that the space to the right of the menu pane reduces below 280mm, the viewport is reduced in width keeping it centred in the available space so that there is the same effect as seen on Android whereby the right hand edge of the document becomes invisible. This is more of a problem on Windows, because the cunning per page horizontal scrolling doesn't seem to work here. You can only see the left hand part of the text.
When the window width reaches the point where the space to the right of the menu pane reduces to 225mm ( and about 9 characters are invisble at the right end of each line) the display switches to remove the menu pane and displays the text left justified with about an 8mm left margin. Further reduction leaves the header a fixed width (running off screen to the right if necessary) and truncates the text at the right leaving an 8mm blank margin.
On Windows it is not possible to move the text so as to be able to see the hidden part once the window gets narrow.
However, on Android, if you switch to split screen mode so that the window is only approx 100mm wide, the menu pane removal works as in Windows but as in the full screen case, the text can be scrolled horizontally on a per page basis so it is possible to read the whole text (somewhat tediously).
Looks like some additional work on the very clever layout algorithm is needed!
Issue migrated from trac:2241 at 2022-03-04 05:47:49 +0000
The text was updated successfully, but these errors were encountered: