Closed zmbq closed 1 year ago
I see the same happens in MS, which is not under your control. This can be solved if you do as I have suggested all along, and create your own copy of MS, that is corrected. If you don't - we're kind of stuck. If we add white-spaces ourselves to every tag end, it can mess with the rendering in case there really isn't a space there. Any ides would be appreciated.
@zmbq This is a tough issue—because it is not so easy to “trade” white spaces between locations in the late stages of the edition pipeline—I have to go back to the stage just following collation to try to micro control it. That is for all the editions. I think I would rather we did not mess with this—it is complicated and quite likely to cause run-together text if misapplied. I think we probably need a quick patch for rendering at the end of the process, not something I try to control in the base texts. You precisely identify the problem spots here—I wonder whether it is programmatically easy to find them and deal with these distinctly for rendering?
@zmbq That said, I will take a look back at the top of my pipeline where all locations in the text are plotted in the first version of the chunk spines— that is where I would need to intervene. I will see if I can do it reliably without harming the Variorum edition files (avoiding run-in text). By the way, we do have my resequenced SGA files in the background if you want to try them.
We can’t identify all those issues. The problem is with variations that start with a whitespace at the end of the line. This changes whenever you resize your window. We may be able to go over everything, remove whitespace from the beginning of the tag and add it to the end of the previous tag – but this will destroy all string-ranges – as a lot of them will be one character off. I don’t know how we can fix this on the visualization end.
From: Elisa Beshero-Bondar notifications@github.com Sent: Saturday, July 6, 2019 11:32 AM To: PghFrankenstein/fv-data fv-data@noreply.github.com Cc: Itay Zandbank itay@chelem.co.il; Mention mention@noreply.github.com Subject: Re: [PghFrankenstein/fv-data] Do not have whitespace at the beginning of tags (#19)
@zmbq https://github.com/zmbq This is a tough issue—because it is not so easy to “trade” white spaces between locations in the late stages of the edition pipeline—I have to go back to the stage just following collation to try to micro control it. That is for all the editions. I think I would rather we did not mess with this—it is complicated and quite likely to cause run-together text if misapplied. I think we probably need a quick patch for rendering at the end of the process, not something I try to control in the base texts. You precisely identify the problem spots here—I wonder whether it is programmatically easy to find them and deal with these distinctly for rendering?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PghFrankenstein/fv-data/issues/19?email_source=notifications&email_token=AAEWI7TRBNAKIBRDDQSJHZLP6BJ67A5CNFSM4H6SV7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKVETA#issuecomment-508908108 , or mute the thread https://github.com/notifications/unsubscribe-auth/AAEWI7TMZUBCR5GDZG27EDDP6BJ67ANCNFSM4H6SV7CQ . https://github.com/notifications/beacon/AAEWI7WOKCSRXDRW4E3HLE3P6BJ67A5CNFSM4H6SV7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKVETA.gif
@zmbq Yeah—that makes sense about messing up the string ranges. It sounds like the high ground is to leave the texts alone and find an alternate way to render. I wonder if there’s a CSS (or SASS) solution here—force the dots on the next line if majority of passage is on the next line...
Both Bill and I have looked into a CSS solution and couldn’t find one.
From: Elisa Beshero-Bondar notifications@github.com Sent: Saturday, July 6, 2019 12:43 PM To: PghFrankenstein/fv-data fv-data@noreply.github.com Cc: Itay Zandbank itay@chelem.co.il; Mention mention@noreply.github.com Subject: Re: [PghFrankenstein/fv-data] Do not have whitespace at the beginning of tags (#19)
@zmbq https://github.com/zmbq Yeah—that makes sense about messing up the string ranges. It sounds like the high ground is to leave the texts alone and find an alternate way to render. I wonder if there’s a CSS (or SASS) solution here—force the dots on the next line if majority of passage is on the next line...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PghFrankenstein/fv-data/issues/19?email_source=notifications&email_token=AAEWI7UVCB4XVTL2SJEKIO3P6BSJRA5CNFSM4H6SV7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKWGRY#issuecomment-508912455 , or mute the thread https://github.com/notifications/unsubscribe-auth/AAEWI7V2FWOK7RUWO5B7JALP6BSJRANCNFSM4H6SV7CQ . https://github.com/notifications/beacon/AAEWI7TGYXX756LPOULDNL3P6BSJRA5CNFSM4H6SV7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZKWGRY.gif
Do either of you do SASS?
I’m in a security line at Frankfurt airport—will poke around through my SASS notes ...
Okay—this isn’t exactly what we need, but it looks like a JS solution to check and respond to white space: https://stackoverflow.com/questions/47008982/how-can-i-detect-white-space-and-delete-delimiter-in-css
This is a world of pain.
It has occurred to me, though, that if we replace all leading spaces with non breaking spaces, it might solve the issue as the browser will need to break the line before the space.
נשלח מ-BlueMail
ב-6 ביולי 2019, 13:13, ב-Elisa Beshero-Bondar notifications@github.com, 13:13 כתב:
Okay—this isn’t exactly what we need, but it looks like a JS solution to check and respond to white space: https://stackoverflow.com/questions/47008982/how-can-i-detect-white-space-and-delete-delimiter-in-css
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/PghFrankenstein/fv-data/issues/19#issuecomment-508914406
@zmbq Looking into this, I probably should not be adding
like that to the variorum-chunks files because it's meaningless in XML, and it's not representing a non-breaking space in the source documents. If the React components are reading the TEI and interpreting for the browser as HTML, that's the point at which they should be added... I'm okay with bending the rules for a moment if it actually works for me to set these into the XML, but this would just be a temporary solution--it's not a good thing to do to the collation data. Let me know if you need an XSLT solution here--otherwise, I think if you can do this in React, that's where it ought to happen.
On the TEI and special characters (as representing the source documents and not for presentation) see https://tei-c.org/release/doc/tei-p5-doc/en/html/WD.html#D25-30
I'll add them in the visualization, do not change the TEI.
נשלח מ-BlueMail
ב-6 ביולי 2019, 20:48, ב-Elisa Beshero-Bondar notifications@github.com, 20:48 כתב:
On the TEI and special characters (as representing the source documents and not for presentation) see https://tei-c.org/release/doc/tei-p5-doc/en/html/WD.html#D25-30
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/PghFrankenstein/fv-data/issues/19#issuecomment-508943247
I’ve added the , but the first example I tried was not caused by a stray whitespace, so this didn’t fix it. So the whitespace is not the only cause for this. We will need to investigate further.
From: Elisa Beshero-Bondar notifications@github.com Sent: Saturday, July 6, 2019 8:47 PM To: PghFrankenstein/fv-data fv-data@noreply.github.com Cc: Itay Zandbank itay@chelem.co.il; Mention mention@noreply.github.com Subject: Re: [PghFrankenstein/fv-data] Do not have whitespace at the beginning of tags (#19)
@zmbq https://github.com/zmbq Looking into this, I probably should not be adding like that to the variorum-chunks files because it's meaningless in XML, and it's not representing a non-breaking space in the source documents. If the React components are reading the TEI and interpreting for the browser as HTML, that's the point at which they should be added... I'm okay with bending the rules for a moment if it actually works for me to set these into the XML, but this would just be a temporary solution--it's not a good thing to do to the collation data. Let me know if you need an XSLT solution here--otherwise, I think if you can do this in React, that's where it ought to happen.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PghFrankenstein/fv-data/issues/19?email_source=notifications&email_token=AAEWI7U2PEQMMTE5XSNZWSTP6DLCHA5CNFSM4H6SV7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZK5WGI#issuecomment-508943129 , or mute the thread https://github.com/notifications/unsubscribe-auth/AAEWI7X2R2TN2V2J3MHEJNLP6DLCHANCNFSM4H6SV7CQ . https://github.com/notifications/beacon/AAEWI7RV3GJQ2D2F7Z6LKKLP6DLCHA5CNFSM4H6SV7C2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZK5WGI.gif
White spaces at the beginning of tags that are the first in a reading group causes a rendering problem - if the space is at the end of a line and the next letter is at the start of the next line (which is controller by the browser, depending on window size, zooming, etc...) - the dots appear at the end of the first line - seemingly disconnected from the text.
There is no simple way to fix this in the visualization code, and if we remove this white space ourselves words are going to appear connected.
So please make sure all the spaces are the end of tags, not at the beginning.