I was randomly searching for help related to old dsp kit6713 and i came across some links,one of interest is below
http://www.geethanjaliinstitutions.com/engineering/labmanuals/downloads/ece/dsp%20lab.pdf
On page 90/91 of document available on above link,there is a code,i have also attached snapshot of that code and highlighted the two lines with yellow color.
I wonder,in last line of snap,which value of filter_coeff (having red mark above)is being used here inside while loop in main function?from the two highlighted lines or the one below highlighted lines ?
In C single line comments begin with // so the two highlighted lines are comments which have no impact on the running code. The filter_coeff in use is the third one, the one that isn't highlighted. Presumably the three options are provided as common defaults. You could comment out the third filter_coeff and uncomment one of the others to change the band range, or you could presumably make your own filter_coeff if you knew exactly which values to use.
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>;
I am using CategoryPointerAnnotation to draw an arrow and show label. Right now the label seems to be too wide. Is it possible to add a line break so that that $ amount shows up on the next line?
CategoryPointerAnnotation ann5 = new CategoryPointerAnnotation("You are here $" +
NumberFormat.getIntegerInstance().format(
num.intValue()), cat, num.intValue(), -2.35619449);
No, line-breaks are not supported. Neither in title, subtitles, labels, tooltips, etc. You can search the JFreeChart forum for "linebreak" or "newline" to find related posts. There have been featuers-requests and according to the forum there were even patches available to fix this, but none has made it into JFreeChart yet (as of 1.0.19).
Have you tried adding in System.getProperty("line.separator")?
like this code
fp1=fopen("Fruit.txt","r");
if(fp1==NULL)
{
printf("ERROR in opening file\n");
return 1;
}
else
{
for(i=0;i<lines;i++)//reads Fruits.txt database
{
fgets(product,sizeof(product),fp1);
id[i]=atoi(strtok(product,","));
strcpy(name[i],strtok(NULL,","));
price[i]=atof(strtok(NULL,","));
stock[i]=atoi(strtok(NULL,"\n"));
}
}
fclose(fp1);
These symbols sound too similar to differentiate their function,can anyone helps me by any method, or use names of shape according to this site http://www.breezetree.com/article-excel-flowchart-shapes.htm
REF:
Used a random online tool to generate this flowchart from your code. http://code2flow.com/
Study more about flowcharts here : http://creately.com/blog/diagrams/flowchart-guide-flowchart-tutorial/
See sample flowcharts here : http://www.conceptdraw.com/samples/flowcharts
Back in the days of FORTRAN, we used that hexagonal symbol on the page you linked to for the "DO" loop, which is basically the same as the modern "for" loop.
So, to draw the loop part of your program I would use that symbol, with a note inside like this:
for i = 0 --> (lines - 1)
Read this as "for i from 0 to (lines - 1)" with the increment of 1 implied by default.
Then the bottom-most box in the loop would have two arrows coming out of it: one straight down to the next statement, and one out the side heading back up to the side of the hexagon.
You could use the diamond to represent "if", but that can obscure the meaning of what you are trying to do, namely execute the loop a certain number of times.
BTW, I don't have high enough reputation yet to post images, so you will have to either follow the link or visualize a hexagon whose center section has been stretched horizontally.
Update: I see that, while I was typing my answer, thecbuilder has also answered this, with a real flowchart. His illustrates how the loop actually works internally, which is fine; mine was intended to show the meaning of the loop on a slightly higher level of abstraction.
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.