In the screenshot of the DOM you can see that the text ending in the numbers 623 is given a x value of 160. However, when I inspect the text, something something which is rendered before the numbers it has a length of 126.08px (see the second screenshot). This means that my text, which I translated 160px to the right, is not actually 160px to the right. From this article, I understand that unless a viewport is provided one user unit should equal one screen unit, but this is obviously not the case here. Why is this? Thanks! I'm using React if that is necessary.
You're setting "text-anchor' to "end' which will end up shifting the text to the left. Set it to 'start' (or possibly skip it altogether) and you should see the behavior you expect.
Related
Below is a picture of my current accessibility tree. You can see that the 4 text leaves in it are separated, but it still forms only one line of content. Is this still accessible well ("well" meaning screen readers can detect that they form one complete sentence), or should all of the text leaves be combined into one leaf?
If they should be combined, how can you concatenate variables into the text in React, while keeping it as one single leaf? This is my current code: <p>{cloudiness}% ({cloudinessDescription})</p>
How they are read aloud depends on the screen reader being used. VoiceOver reads it as one phrase, but that doesn't mean others will. Having it split up wouldn't be a nice experience, but it doesn't mean it's not accessible.
If you really want to make sure it's read as one phrase but don't like the noise of the template literal inside the JSX (I agree), why not define the string somewhere else until you are able to test on multiple screen readers?
const cloudinessSummary = `${cloudiness}% (${cloudinessDescription})`;
return <p>{cloudinessSummary}</p>;
can any one explain why(how) the xtype: numberfield value is going to auto correct(change) if am providing more than a 16 digits value.
For Example:
22222222222222222 is changed to 22222222222222224
222222222222222222 is changed to 222222222222222200
2222222222222222222 is changed to 2222222222222222300
22222222222222222222 is changed to 22222222222222220000
222222222222222222222 is changed to 222222222222222230000
2222222222222222222222 is changed to 2.2222222222222222e+21
22222222222222222222222 is changed to 2.2222222222222223e+22
Which results in my page after rendering as shown below when get the value through in my component jsp page
NumberFieldTestValue:<%= properties.get("numberfieldname","") %>
Resulting as below
NumberFieldTestValue: 2.2222222222222223e+22
The problem
This behavior is caused by the fact that the dialog behavior is implemented in JavaScript. The numbers you're having problems with cannot be represented in it.
The language conforms to the ECMASCRIPT 5.1 specification.
To quote the Number type description
all the positive and negative integers whose magnitude is no greater
than 2^53 are representable in the Number type
The base 2 logarithm of 2222222222222222222222 is about 70, which means the number exceeds the maximum value. Hence your problems.
All in all, if you check your examples in a plain JS console in a browser, the same behavior will be displayed so this is not really a CQ problem.
Solution 1 - use a different type
To avoid this, you could potentially use xtype="textfield" and validate it against a regular expression to see if it consists of numbers only. Then you'd have to make sure to use a type capable of holding such numbers at the backend (like BigInteger).
The field could look like this:
<numberOfSandGrains
jcr:primaryType="cq:Widget"
fieldLabel="Number of grains of sand at the beach"
name="./grainsCount"
regex="/\d+/"
regexText="Please enter a numeric value."
xtype="textfield"/>
Solution 2 - change scale
Another option is to change the logic behind the configuration and use some different units if applicable. For instance, if the value 2222222222222222222222 is a number of grams (weight of an object/substance), it makes perfect sense to read it in metric tons instead (at least in many cases). The author could probably do without entering such humongous numbers.
You'll need to be extra-careful if you go this way.
The glass docs made it look so easy!
I can get my map drawn with start and end points, but the polyline to connect the two isn't getting rendered.
Here's a simple one:
glass://map?w=240&h=360&marker=0;28.036352,-82.422457&marker=1;28.044039,-82.421721&polyline=28.036352,-82.422457,28.044039,-82.421721
After a night and a day of throwing everything at it, still no joy. I must be Doing it Wrong(tm) ... I hope someone sees a problem hidden in plain sight (at least to me).
You're missing a semicolon right after polyline=. Here's the corrected URL:
glass://map?w=240&h=360&marker=0;28.036352,-82.422457&marker=1;28.044039,-82.421721&polyline=;28.036352,-82.422457,28.044039,-82.421721
The documentation says
Each polyline consists of a width and color followed by the vertices in the polyline. For example: polyline=8,ffff0000;47.6,-122.34,47.62,-122.40 specifies an 8-pixel wide red line between (47.6,-122.34) and (47.62,-122.40).
The proper format for a 2-point polyline is therefore:
polyline=WIDTH_IN_PIXELS, COLOR_IN_HEX; START_POINT_LAT, START_POINT_LONG, END_POINT_LAT, END_POINT_LONG,
You need to specify the semicolon to denote the end of the width, color tuple.
I am creating a text editor as a way of getting more familiar with C and gtk+. I am using gtk+-2.0 & gtksourceview-2.0, and gtk_scrolled_window . As a first attempt at creating a goto function browser I thought I would just simply create an array of functions found in the document and a corresponding array of lines on which they occur. I have that much done. I was surprised to find that there is no goto line capability that I can easily find in devhelp. It sounds like gtk_text_view_scroll_to_mark () is what I want (after creating a mark), but all the *scroll_to functions require a within_margin, which to be honest I don't really understand.:
From devhelp:
The effective screen for purposes of this function is reduced by a margin of size within_margin.
What does that mean?
Am I even close? How can I create this scroll to line number functionality?
Thanks.
UPDATE: The following three functions were used to scroll to a line in the buffer:
gtk_text_iter_set_line (&start, lineNums[9]);
gtk_text_buffer_add_mark (tbuffer, scroll2mark, &start);
gtk_text_view_scroll_to_mark (text_view, scroll2mark, 0.0, TRUE, 0.0, 0.17);
The last parameter of gtk_text_view_scroll_to_mark was used to get the target line number to line up with the very top line in the buffer. I imagine this parameter will not work on all screen sizes, but I have not tested it.
The gtk_text_view_scroll_mark_onscreen function got me close to the line number, but it was just a couple of lines off the bottom of the text area.
The within_margin parameter controls the area of the screen in which the scrolled-to text should appear or more precisely it sets the amount of space at the border of the screen in which the text should not appear.
This exists so that when you set use_align to false (i.e. you don't want the text to appear at a specific position on the screen), you can still make sure that the text doesn't appear directly at the top of bottom of the screen (which might be bad for readability purposes).
If you don't care at all about the position at which the text will appear, you can use g_text_view_scroll_mark_on_screen which only takes the text view and a mark and no further arguments. This will always scroll the minimum amount to make the text appear on screen.
I'm currently writing an eBook reader for Windows Phone Seven, and I'm trying to style it like the Kindle reader. In order to do so, I need to split my books up into pages, and this is going to get a lot more complex when variable font sizes are added.
To do this at the moment, I just add a word at a time into the textblock until it becomes higher than its container. As you can imagine though, with a document of over 120,000 words, this takes an unacceptable period of time.
Is there a way I can find out when the text would exceed the bounds (logically dividing it into pages), without having to actually render it? That way I'd be able to run it in a background thread so the user can keep reading in the meantime.
So far, the only idea that has occurred to me is to find out how the textblock decides its bounds (in the measure call?), but I have no idea how to find that code, because reflector didn't show anything.
Thanks in advance!
From what I can see the Kindle app appears to use a similar algorithm to the one you suggest. Note that:
it generally shows the % position through the book - it doesn't show total number of pages.
if you change the font size, then the first word on the page remains the same (so that's where the % comes from) - so the Kindle app just does one page worth of repagination assuming the first word of the page stays the same.
if you change the font size and then scroll back to the first page, then actually there is a discontinuity - they pull content forwards again in order to fill the first page.
Based on this, I would suggest you do not index the whole book. Instead just concentrate on the current page based on a "position" of some kind (e.g. character count - displayed as a percentage). If you have to do something on a background thread, then just look at the next page (and maybe the prev page) in order that scrolling can be more responsive.
Further to optimise your experience, there are a couple of changes you could make to your current algorithm that you could try:
try a different starting point and search increment for your algorithm - no need to start at one word and to then only add one word at a time.
assuming most of your books are ASCII, try caching the width of the common characters, and then work out the width of textblocks yourself.
Beyond that, I'd also quite like to try using <Run> blocks within your TextBlock - it may be possible to get the relative position of each Run within the TextBlock - although I've not managed to do this yet.
I do something similar to adjust font size for individual textboxes (to ensure they all fit). Basically, I create a TextBlock in code, set all my properties and check the ActualWidth and ActualHeight properties. Here is some pseudo code to help with your problem:
public static String PageText(TextBlock txtPage, String BookText)
{
TextBlock t = new TextBlock();
t.FontFamily = txtPage.FontFamily;
t.FontStyle = txtPage.FontStyle;
t.FontWeight = txtPage.FontWeight;
t.FontSize = txtPage.FontSize;
t.Text = BookText;
Size Actual = new Size();
Actual.Width = t.ActualWidth;
Actual.Height = t.ActualHeight;
if(Actual.Height <= txtPage.ActualHeight)
return BookText;
Double hRatio = txtPage.ActualHeight / Actual.Height;
return s.Substring((int)((s.Length - 1) * hRatio));
}
The above is untested code, but hopefully can get you started. Basically it sees if the text can fit in the box, if so you're good to go. If not, it finds out what percentage of the text can fit and returns it. This does not take word breaks into account, and may not be a perfect match, but should get you close.
You could alter this code to return the length rather than the actual substring and use that as your page size. Creating the textblock in code (with no display) actually performs pretty well (I do it in some table views with no noticeable lag). I wouldn't send all 120,000 words to this function, but a reasonable subset of some sort.
Once you have the ideal length you can use a RegEx to split the book into pages. There are examples on this site of RegEx that break on word boundaries after a specific length.
Another option, is to calculate page size ahead of time for each potential fontsize (and hardcode it with a switch statement). This could easily get crazy if you are allowing any font and any size combinations, and would be awful if you allowed mixed fonts/sizes, but would perform very well. Most likely you have a particular range of readable sizes, and just a few fonts. Creating a test app to calculate the text length of a page for each of these combinations wouldn't be that hard and would probably make your life easier - even if it doesn't "feel" right as a programmer :)
I didn't find any reference to this example from Microsoft called: "Principles of Pagination".
It has some interesting sample code running in Windows Phone.
http://msdn.microsoft.com/en-us/magazine/hh205757.aspx
You can also look this article about Page Transitions in Windows Phone and this other about the final touches in the E-Book project.
The code is downloadable: http://archive.msdn.microsoft.com/mag201111UIFrontiers/Release/ProjectReleases.aspx?ReleaseId=5776
You can query the FormattedText class that is used AFAIK inside textBlock. since this is the class being used to format text in preparation for Rendering, this is the most lower-level class available, and should be fast.