I have noticed that core spotlight description get truncated even if description character length is under 150.
Apple says : As with titles, long descriptions can also get truncated, so it’s best to limit your description to 300 characters.
I was wondering Why the core spotlight description get truncated even though the character length is less than 150 as Apple recommended to have limit 300.
Appreciate your help.
If I remember correctly, you can manually insert a newline in the title string, and it will use 2 lines, but will not autowrap to the next line without it.
How much truncation will happen depends on various factors, including but not limited to:
the avatar size
the title length
whether its a top hit result or a normal suggestion
Also new line \n doesn't work in Content description. I suggest you can separate different values using | sign. Core light Search result UI is very limited in terms of how much you can customise.
Related
I was wondering if CLoudWatchLogs has a limit on the length of 1 line of logging. I checked the CloudWatchLogs Limit documentation page, but they do not specify anything regarding line length limit.
They do mention the Event size limit (256 KB) , which is the maximum size of 1 event, but that does not tell me anything about the length of the line. A log event can contain more information than only the #message field.
Looking into this a bit (since I was curious about the same thing). The boto3 python client documentation refers to log lines as events. The event consists of the timestamp and the message. Within various AWS tools, the message can be broken into various fields, but I believe the timestamp and message are the only actual fields in the log event.
So this would suggest that about 256K is the maximum size for each line (minus the size of the timestamp and probably some overhead as well).
This is not to say that the AWS web console will handle lines that long well though.
The maximum event size is ~256kB, events longer than that will fail (they are not truncated). This size includes 26 bytes of metadata (10 bytes of timestamp and 16 of field names).
This can be verified with this boto3 script.
I tried to console.log a big file( around 800 KB), in cloudwatch I can see 4 console.log message first 3 with around 250 KB size, and rest in the last.
So from my experience line numbers do not matter only the total size of each event matters.
As per our business requirement, I need to index full story body (consider it for a news story for example) but in the Solr query result I need to return a preview text (say, first 400 characters) to bind to the target news listing page.
As I know there are 2 options in schema file for any field stored=false/true. Only way I can see as of now is I set it to true and take the full story body in result and then excerpt text to preview manually, but this seems not to be practical because (1) It will occupy GBs of space on disc for storing full body and (2) the json response becomes very heavy. (The query result can return 40K/50K stories).
I also know about limiting the number of records but for some reasons we need complete result at once.
Any help for achieving this requirement efficiently ?
In order to display just 400 characters in the news overview, you can simply use Solr Highlighting Feature and specify the number of snippets and their size. For instance for Standard highlighter you have parameters:
hl.snippets: Specifies maximum number of highlighted snippets to generate per field. It is possible for any number of snippets from
zero to this value to be generated. This parameter accepts per-field
overrides.
hl.fragsize: Specifies the size, in characters, of fragments to consider for highlighting. 0 indicates that no fragmenting should be
considered and the whole field value should be used. This parameter
accepts per-field overrides.
If you want to index everything but store only part of the text then you can follow the solution advised here in Solr Community.
What i'm curious about is lets say I have 100 pdfs. And all of them have the words "happy apple". Lets say that only 20 of these have embedded text that has "happy apple".
When i do a search for "happy apple" will i receive all 100 docs or only 20? I'm unable to find a clear answer on this question.
Flat out impossible to answer without any further information on your search tool and the actual PDFs.
"Happy apple" will be found if the text is 1. not compressed, 2. not encrypted, 3. not weirdly constructed, 4. not re-encoded, or 5. re-encoded but the translation table to Unicode is present and correct.
ad 1: Usually data streams in a PDF are compressed, using one or more algorithms from the standard set (usually LZW or Flate).
ad 2: PDFs may be encrypted with a password, preventing casual inspection. Levels of security range from mid-difficult to theoretically uncrackable with current technology.
ad 3: Single characters may appear on your page in any order. The software used to create it may, at its whim, split up text string in separate parts or even draw each individual character at any position, and omit all spaces. Only strict sorting on absolute x and y coordinates of each text fragment may reveal the original text.
ad 4: If a font gets subsetted, a PDF composer may decide to store 'h' as 0, 'a' as 1 and 'p' as 2 (and so on). The correct glyphs are still associated with these codes, but "the" text now may appear as "0 1 2 2 3 4 1 2 2 5 6" in the text stream. Also, even if it does not subset the font, a PDF composer is free to move characters around anyway.
ad 5: To revert this re-encoding, software may include a ToUnicode table. This is to associate character codes back to the original Unicode values again; one table per re-encoded font. If the table is missing, there usually is no straightforward way to create it.
There is even an ad 6 I did not think of: text may be outlined or appear in bitmaps only.
Only the very simplest PDFs can be searched with a general tool such as command-line grep. For anything else, you need a good PDF decoding tool -- and the better it is, the more points of this list you can tick off. Except, then, #5 and #6.
(Later edit) Oh wait. You obfuscated your actual question enough to entirely throw me off the target, which (I think!) was "does sql-server-2008 search for entire phrases or for individual words?"
Good thing, then, the above still holds. If you cannot search inside your PDFs anyway, the actual question is moot.
I'd like to know if there is a way to predict the size of a .doc based on the number of pages it contains.
I'm trying to form a rough estimate of how much storage space I need when anticipating X number of .doc's of Y page length.
For example: "I need to plan for 100 .DOC files, each being 15 pages in length. These .DOCs will consume roughly _KB of space."
Thanks
Not really. There's too many variables.
For example, a .doc (Word 2003) containing a page of nothing but the character 'a' in one font takes up 37kb, in another the same number of characters takes 32kb, in another 43.
The most practical way would be for you to average the sizes of the sample files, and work off that, but be aware that the smallest change can have rather large effects.
I've building a very basic iphone app where the user will be able to enter or select a very large numeric cash value (usually in the thousands or millions).
At the moment I am using a simple text box entry with number pad selected.
I am going to use the example of a Football transfer fee as an analogy.
A transfer fee can be in many millions and I really do not want the user to be mis-typing zero's, or getting frustrated with the number of zero's they have to enter.
In addition, as the text box/numeric cash value is not displayed with any currency formatting it makes it very unintuitive to know just how much you are entering.
In this thread I have a way of displaying big numbers on the screen; you'll also notice the numbers are formatted in chunks (ie: 2.25m, 2m, 7.25m, etc) -- it makes the process more streamlined and is more visually intuitive.
But what I am unsure about is how to make it easy for the user to enter big numbers without typing stupidly long zeros every time.
Possible solution 1 -- Use a UIPickerView with 3+ segments for each of the units.
Problem -- it won't handle smaller numbers properly, also you may get weird looking numbers like 1.15k which although correct is not what I want to display.
Possible solution 2 -- Use a +/- button to allow a user to simply increase/decrease the number by a factor of 250 or 500. This is the simplest answer, but its not as elegant as a UIPickerView
If there is another way to do this, a way to simplify the input of big numeric numbers from a user, I'd be interested.
You could add formatted output right above or below the text field. As they enter numbers, update the formatted field adding currency symbols, commas and decimals. Not the most elegant way to do this, but it would be simple to implement, and intuitive to the user.