How do you use SetAutoPageBreak in fpdf if you want it to be enabled? On the net I've found all sorts of variants:
$p->SetAutoPageBreak(1,20);
$p->SetAutoPageBreak(true,20);
$p->SetAutoPageBreak('true',20);
$p->SetAutoPageBreak(on,20);
$p->SetAutoPageBreak('on',20);
$p->SetAutoPageBreak('on','20');
Thanks!
SetAutoPageBreak accepts a boolean value for it's first parameter so all the examples you have shown are valid.
See the PHP manual for details on what values are evaluated to true/false. Personally, I would use true or maybe 1. It's clear and easy to understand when you review your code in the future.
Are you having trouble with the output or was it just a curiosity question?
EDIT:
MultiCell is just that, it has multiple cells, to allow for line breaks etc. The page break will only occur if one of the cells breaches the limit and even then it will just break for that cell. So, in effect a paragraph of text over multiple lines may be split across two pages, but the last line on the page won't breach the margin limit.
You might want to consider using cell or, forcing a page break using AddPage.
Related
Prefixing the link with an ! suppresses the creation of a reference (e.g. :ref:`!no link` will be simply rendered as no link):
If you prefix the content with !, no reference/hyperlink will be created.
However, I can't think of any practical usage of this. Why should I first create a reference and then don't want to use it - it would be far easier to write plain text from the very beginning.
So - what is a typical use case of such a suppressed reference?
(Sphinx itself for instance doesn't use it in its docs.)
I can't think of any practical usage of this.
The use I can think of is before a build if you wanted to "turn of" hyperlink generation for one given cross-reference (that appears multiple times) how would you do it?
Well, the simplest way might be using some text editor's "find and replace", and arguably the least invasive way would be to add or remove a single character !. That way the length and structure of the cross-reference is kept in the source (and the title is still rendered in place). This could be convenient in several places, like a table where removing the whole cross-reference could misalign the source.
The most economical change possible would be turning this:
:ref:`a very long title <an.extremely.long.link.target>`
into this:
:ref:`!a very long title <an.extremely.long.link.target>`
The same could possibly be achieved programmatically using the Sphinx API, but a lot of Sphinx users are likely to prefer a text editing solution over a programmatic one.
Im trying to learn bourbon-neat, came across its breakpoint feature that takes a query and grid-columns. What is the use of grid-columns there? Why would you set the grid-columns like that when you can change the columns on the fly with declaration to span-columns?
Just need abit more explanation as to why you will provide a second parameter.
It is just to provide a little more flexibility. You may never use it, but for instance you may wish to have a 12 column grid for large screens and a 5 column grid for smaller columns. In this instance span-columns would not work as 12 cannot be divided by 5.
Admittedly you may not use it that often!
I filtered my report based on a certain expression. Those that do not meet the criteria that I put in my IFF expression are then filtered and those that do meet it, are shown in my report. My report is multiple pages, so when the filtering happens, some records are left alone on a page, and are not moved up. This leaves a lot of whitespace, and I would like to get rid of that.
On page 1, there will be 2 images/records, with space for one more
On page 2, there will be only 1 image/record that would fit on page one, but doesn't move up
on page 3, there will be only 1 image/record that would fit on page 2 but stays on page 1 etc...
my Keeptogether value is set to true, however this does not help. I have been trying to find something that will keep these records together when filter happens, so that the number of pages is minimal.
If someone could help, I'd really appreciate it.
Regards
Jay
Are you "filtering" via the Visibility in Properties? Because such way will just hide, rather than rule out, the records/images you don't want. If that's the case, try filtering via the Filter in the Properties of the tablix (or Groups, if it applys to your case). But I think the best way is to do the filter job in you data set query, because that will provide you best performance.
So i resolved my problem by adding my IFF expression that I orginially had in the visibility option to the filter by expression option. Everything now moves up and the extra white space that was there before is gone.
Thank you for your help!! :)
Am wondering if the combination of trim(), strip_tags() and addslashes() is enough to filter values of variables from $_GET and $_POST
That depends what kind of validation you are wanting to perform.
Here are some basic examples:
If the data is going to be used in MySQL queries make sure to use mysql_real_escape_query() on the data instead of addslashes().
If it contains file paths be sure to remove the "../" parts and block access to sensitive filename.
If you are going to display the data on a web page, make sure to use htmlspecialchars() on it.
But the most important validation is only accepting the values you are expecting, in other words: only allow numeric values when you are expecting numbers, etc.
Short answer: no.
Long answer: it depends.
Basically you can't say that a certain amount of filtering is or isn't sufficient without considering what you want to do with it. For example, the above will allow through "javascript:dostuff();", which might be OK or it might not if you happen to use one of those GET or POST values in the href attribute of a link.
Likewise you might have a rich text area where users can edit so stripping tags out of that doesn't exactly make sense.
I guess what I'm trying to say is that there is simple set of steps to sanitizing your data such that you can cross it off and say "done". You always have to consider what that data is doing.
It highly depends where you are going to use it for.
If you are going to display things as HTML, make absolutely sure you are properly specifying the encoding (e.g.: UTF-8). As long as you strip all tags, you should be fine.
For use in SQL queries, addslashes is not enough! If you use the mysqli library for example, you want to look at mysql::real_escape_string. For other DB libraries, use the designated escape function!
If you are going to use the string in javascript, addslashes will not be enough.
If you are paranoid about browser bugs, check out the OWASP Reform library
If you use the data in another context than HTML, other escaping techniques apply.
I made a report with about 30 different rectangles and textboxes that have different visibility expressions depending on the parameters. (It's a student invoice and many different messages have to appear depending on the semester) When I made all the expressions I coded in the parameters in all upper case. Now I have a problem when users enter lowercase letters, the SQL all works fine since it is not case sensitive, but the different rectangles and textboxes don't show. Is there a way in the report code to first capitalize all the parameters before running the SQL? Or do I actually have to go back to every visibility expression and add separate iif's for upper and lower case? (That seems incredibly silly to have to do). I can't change my parameters to numbers because I have been given strict requirements for input. Thanks.
I do not know if this is the most elegant solution, but you could accomplish this by following this procedure for every parameter on the Report Parameters page:
1)Re-name the parameter, leaving its prompt as that of the old parameter.
2)Add a new parameter with the same name as the old parameter.
3)Mark this new parameter as Hidden.
4)Make sure that the new parameter's available values are marked as non-queried(available values will never be actually used.)
5)Mark the Default Values as Non-queried, using the following syntax:
=ucase(Parameters!OldParameterName.Value)
Can't you just UCASE the params (do it in the xml view, it will be quicker and you might even be able to do a regex find/replace)