Upgrade StorageRe: Generate Report: truncated line width
Given an Item created from a current page,
and the URL of the Item is quite long,
and an Abstract of the Item was inserted into the Item record,
And
The URL of the Item is wider than the width of the "box" allowed on the Report (and is not folded into two lines),
Then
The lines of the URL and the Abstract may be truncated around where the right boundary of the "box" would be (the right-hand "box" border is missing).
I do not have a case in which a Note exists under the discrepant conditions above.
and the URL of the Item is quite long,
and an Abstract of the Item was inserted into the Item record,
And
The URL of the Item is wider than the width of the "box" allowed on the Report (and is not folded into two lines),
Then
The lines of the URL and the Abstract may be truncated around where the right boundary of the "box" would be (the right-hand "box" border is missing).
I do not have a case in which a Note exists under the discrepant conditions above.
While we could insert characters to allow the URL to break, that would mean the URL could no longer be copied into the address bar. (I haven't verified that all of the possible Unicode break characters are included when you copy something to the clipboard and parsed in URLs, but I'm guessing they are. If someone wants to test this, though, that'd be helpful.)
On the other hand, if the URL is an actual link, having a break in the middle when displayed might not matter too much...
>>> if Zotero folks would explain the fontSize extension.
Workaround (works for me in most cases):
Generate the Report in a new tab after using Firefox | Tools | Options | Content to set Default Fonts & Colors to a smaller font size (in my case from 14 to 10). This will allow most of my URLs to fit, and those abstracts as well. If you forget to set the smaller size before the Report is generated, set smaller in Options and then click the "refresh" on the toolbar.
Possible Solution:
Under Firefox About:Config, locate "extensions.zotero.fontSize" which is defaulted to string with value 1.0. If we knew what the allowed values are, perhaps we could store the extension.
More:
Zotero will do a line break on a URL if it detects a "?" character. I can't figure out why "?" but no other.
So I guess what I said above about it probably being OK to break the URL up as long as it's properly linked...is something we're already doing.
We could start adding optional line breaks at forward slashes (which would be invisible unless Firefox needed to wrap), but since Zotero doesn't have any way of knowing how many characters will fit on a line, it would have to add these in in any fairly long URL, and if the line didn't happen to wrap and a user tried to copy and paste the URL rather than using the link, it would probably result in a confusing 404 page due to the spaces. But that may still be a better solution than letting lines run long.
I can tell you have a depth of knowledge far beyond what I have picked up by RTFM and experimentation.
I have found that even truncated URLs still work in the Report and even in a PDF of the Report in the browser (print to deskPDF). This will support getting back to the Title source to see if it has been changed since capture.
Let me tell you what I'm trying to do:
I am trying to sort out a sense of the truth in a controversial subject. The environment is an exchange of "snowballs" in support and dissent (actually, iceballs and rocks). Zotero was recommended, and has a good fit to capture, source, annotate, organize (subCollection) and tag (index). The "Related" feature is useful to indicate other items (Titles) which should be manually reviewed in the controversy.
Herein lies the rub. I can't find any feature that identifies How and Why one Title is Related to another Title.
I don't think that the "rules" for handling this situation as a data base belong in Zotero. Too complex for good performance. Perhaps in a personal database that links to Zotero if I can find out how to link it.
Each "Title" may contain 1 or more "Claim"s.
Each "Claim" belongs to exactly one "Title".
Each "Claim" may reference one or more "Related_Claim"s.
Each "Related_Claim" Belongs To exactly one "Claim".
Each "Related_Claim" Refers To exactly one (different) "Claim".
a. A "Related_Claim" may be classified as supporting or dissenting.
b. A "Related_Claim" may be described in terms of the impact.
c. No "Related_Claim" may Refer To the "Claim" to which it Belongs.
These rules resemble those of a Bill Of Materials; that would raise the problem of preventing cycling ("A" consists of "B" & "C"; "C" consists of "A"& "D"; and so on forever).
Thank you again, Dan, for bearing with me.
Bullseye!
Shall I post "the 'rules' for handling this situation" (above) to the Semantic Relations thread?
I could diagram it if I can figure out a way to post a graphic (ERD) to the thread.
Thanks again, Dan
I'll work on posting a diagram to Trac once I figure out how to do that.
Meanwhile, if that takes a while, the "rules" are actually "Semantic Analysis" or "Semantic Design", depending on how far along it is. It's currently a preliminary "Analysis". The comments in "Semantic Relations" have already expanded my thinking.
My rule-of-thumb is that if I can not describe a diagram (ERD) as a Semantic Analysis/Design that makes to customers (users), then I don't have a Design.