As we can see on lots of web site : we can increase or decrease size of font. Like on this example : http://blog.creonfx.com/examples/javascript/dynamic-font-resize.html
Is this possible in GWT ?
So could I change general (= all widgets) font size dynamically by choosing a size in a combo (1, 2, 3) like on the image ?
Depending of the widget, for example the ones which have a content property which could be set with Html should be feasible I think....
If you can get a reference to the DOM element you want to change you would probably be able to change the style via some specific javascript.
But in any case I don't think there is a direct way of doing it and on any widget.
You can have a look to this thread also which indicate this fact.
Related
By default Autocomplete seems to show 8 suggestions at a time, the rest you will have to scroll down to see it. There are no component property related to this number in Antd documentations. Is there any way to change that to another fixed number? How about making it display all?
Internally Autocomplete use the component Select and make all Select properties available, even internal props. listHeight can be used to increase the height of the suggestion dropdrown list. As note in Antd's Select documentation:
Virtual scroll internal set item height as 32px
To make Autocomplete display 10 items for example, set listHeight={320} to Autocomplete. To make it display all items, pass an arbitrary large number to listHeight like 999999 or Number.MAX_SAFE_INTEGER
I would like to rip off Google's design for my Continuous Form. The detail section of the form is set up to display N number of records resulting from a search, and thus cannot be used to create this effect (i think). Everything must go in the header section.
there are 2 primary issues I would like to address in this question:
Two toned background. The header section should have a grey stripe and a white stripe. This stripe needs to extend the full width of the form, which is variable and will depend on the user. (i'm using tabs not pop-ups)
How to right justify certain elements of the header so that they stay close to the right edge, wherever that may fall, just like your account information on Google.
The "Search Results" in the detail section are loaded by setting the form's recordSource to the results of a query defined in VBA, which takes parameters from the search box. The form is continuous.
Any ideas how to hack this into place?
Recent versions of MS Access provide improved form layout features when using the ACCDB database file format.
The screen captures below are based on a form in Access 2010. The second image is after the form width was expanded, but it's scaled down for display on this web page. However you can open those images directly to compare their relative widths.
The grey color is from the form header's Back Color property. The white box is a simple text box whose Back Color is white and Back Style is Normal (not Transparent).
The text box's Horizontal Anchor property is Both, and its Can Grow property is Yes. The other 3 items ("?", "Button 2", and "Button 3") are command buttons. Their Horizontal Anchors are set to Right and their Can Grow properties are No.
The result of those properties is that when the form expands, those command buttons maintain their size are are kept right-aligned within the form. And the text box stretches to fill the remaining available space.
Note this behavior is accomplished without any VBA code.
I think these layout capabilities were introduced in Access 2007 and perhaps refined in 2010.
For the background, use two rectangles with transparent borders, one back color gray, one white. You can size them to the form by using the form's InsideWidth property. For example:
Private Sub Form_Resize()
rect1.Width = Me.InsideWidth
rect2.Width = Me.InsideWidth
End Sub
I would do a similar thing for the buttons/images/etc you want right justified. Set their Left property relative to the form's width:
mySettingsButton.Left = Me.InsideWidth - 300
Keep in mind all the measurements are twips (1440 twips/inch)
I created a .PDF file using Adobe Acrobat Pro. The file has several text fields. Using iTextSharp, I'm able to populate all the fields and mail out the .PDF.
One thing is bugging me - some of the next will not "fit" in the textbox. In Adobe, if I type more that the allocated height, the scroll bar kicks in - this happens when font size is NOT set to auto and multi-line is allowed.
However, when I attempt to set the following properties:
//qSize is float and set to 15;
//auto size of font is not being set here.
pdfFormFields.SetFieldProperty("notification_desc", "textsize", qSize, null);
// set multiline
pdfFormFields.SetFieldProperty("notification_desc", "setfflags", PdfFormField.FF_MULTILINE, null);
//fill the field
pdfFormFields.SetField("notification_desc", complaintinfo.OWNER_DESC);
However upon compilation and after stamping, the scroll bar does not appear in the final .PDF.
I'm not sure if this is the right thing to do. I'm thinking that perhaps I should create a table and flood it with the the text but the documentation makes little or no reference to scroll bars....
When you flatten a document, you remove all interactivity. Expecting working scroll bars on a flattened form, is similar to expecting working scroll bars on printed paper. That's why you don't get a lot of response to your question: it's kind of absurd.
When you fill out a rectangle with text, all text that doesn't fit will be omitted. That's why some people set the font size to 0. In this case, the font size will be adapted to make the text fit. I don't know if that's an option for you as you clearly state that the font size must be 15 pt.
If you can't change the font size, you shouldn't expect the AcroForm form field to adapt itself to the content. ISO-32000-1 is clear about that: the coordinates of a text field are fixed.
Your only alternative is to take control over how iText should fill the field. I made an example showing how to do this in the context of my book: MovieAds.java/MovieAds.cs. In this example, I ask the field for its coordinates:
AcroFields.FieldPosition f = form.GetFieldPositions(TEXT)[0];
This object gives you the page number f.page and a Rectangle f.position. You can use these variables in combination with ColumnText to add the content exactly the way you want to (and to check if all content has been added).
I hope you understand that:
it's only normal that there are no scroll bars on a flattened form,
the standard way of filling out fields clips content that doesn't fit,
you need to do more programming if you want a custom result.
For more info: please consult "iText in Action - Second Edition".
Using the RichTextArea in GWT, It looks like I can only change the font size to one of the values: LARGE, MEDIUM, SMALL, etc (RichTextArea.FontSize), but I want to be able to setFontSize of the RichTextArea.Formatter to a specific size in pt or in px.
How can I achieve that?
I've been digging a bit on this, and it would seem that it is unfortunately not possible, because browsers are limited in their handling of font sizes in the rich text editors. In particular, Firefox generates the (deprecated) <font size="x"></font> element when the font size is changed, and the value of x can be only in the 1-7 range.
If you have a look at the setFontSize method in RichTextAreaImplStandard (GWT source code), you'll see that it ends up calling the execCommand javascript function, which in the case of FontSize only accepts values in 1-7:
http://msdn.microsoft.com/en-us/library/ms536991%28VS.85%29.aspx
You can actually achieve that using string manipulation of the HTML code.
So if you are not using the background color property of the RichTextArea then what you have to do is to replace the "background-color=RED" to "font-size=12px". And then set it back to the RichTextArea object as setHTML().
This works fine as I've implemented this functionality in one of our production application..
Thanks,
Pratik.
How to slice some text (html) string into number of pages to be possible read text as a book?
Thanks for suggestions.
Assuming you are happy recognising only a subset of HTML markup without CSS (here I assume <p/><b/><i/><br/> tags only plus <font size=/> for font size changes (with other attributes ignored), <img> tags for images with all but src,width,height ignored and accurate width and height mandatory with all other tags/attributes ignored):-
TidyLib seems to have an MIT license - http://tidy.sourceforge.net/#source
SAX parse the XHTML output of TidyLib using NSXmlParser into a custom object model (unless you are exclusively using later versions of iPhone OS with public builtin DOM parser API in which case just use a DOM object model).
Set up a state machine with a caret position at top left of page and initial font size and formatting, page number of 1, maximum height of glyphs/images in current line of zero, and empty list of page boundaries.
For each run of text or image in object model, apply pre-ceding font size/format modifications, measure text using iPhone text measurement calls, reducing text length (trim to nearest space or hyphen) until it fits on current line, and resetting caret to line beginning and continuing for line wraps, and apply following font size and formatting changes. Over-count the width and height of text by some factor in cases where this is found to be required to prevent page overflow in the actual page rendering engine (UIWebView; you will have to experiment to see what the factors in the rendering engine are). Record page boundary in list.
Convert objects between page boundaries to simplified XHTML for each page. You may wish to add some CSS at this point for example to format link colours. You will need to convert local references to anchors on another page to load the correct other page. Perhaps add page footer/header with page numbers (subtract size of these from page height in earlier steps).
Save XHTML as set of files.
In essence this will work as long as the source HTML is specially prepared to use a subset of HTML for your app. Any old HTML will not do, though it might perhaps not be completely useless to give a rough idea for previews in some instances for some files.
The description above assumes you throw away formatting like ALIGN= and tables. It really is a very basic approach and will not reproduce complex pages as originally designed! It might well not suit you!
Perhaps the files should be pre-processed before reaching the iPhones in the field but if the iPhone OS / WebView line-wrapping/test positioning behaviour changes, the best position for page breaks may change. So you may need to cut your pages smaller than you think they need to be to allow for some unexpected growth when the rendering engine changes. Hmm. Perhaps not an easy task!
I haven't even tried to analyse HTML tables... HTML is of course, in its non-restricted full glory enormously probably unmanageably complex.