According to Adobe's Manual on PDF Open Parameters PDF files can be opened with certain parameters from command line or from a link in HTML.
These open Parameters include page=pagenum, zoom=scale, comment=commentID and others (the first parameter should be preceded with a # and the next should be preceded with a &
The official PDF Open Parameters from adobe gives this example:
#page=1&comment=452fde0e-fd22-457c-84aa-2cf5bed5a349
but the comment part doesn't work for me!
page=pagenum and zoom=scale work for me well. But comment=commentID does not work. I tried on Adobe reader 6.0.0 and Adobe Pro Extended 9.0.0: I can't get to the specified comment.
Also, I get the comment ID by exporting the comments in XFDF format and in the resulting file, there is a name attribute for every comment that I hope corresponds to the ID (well, the appearance looks like the example in the manual).
I thought maybe there is a setting that I should first enable (or maybe disable in adobe) or maybe I am getting the comment IDs wrong, or maybe something else?!
Any help would be extremely appreciated
According to the docs, you must include a page=X along with your comment=foo. Your copied sample has it, but it's copied from the docs, not something you did yourself.
Are you missing a page= when setting comment?
BASTARDS!
From the last page of the manual you linked:
URL Limitations
●Only one digit following a decimal point is retained for float values.
●Individual parameters, together with their values (separated by & or #), can be no greater then 32 characters in length.
Emphasis added.
The comment ID is a 16-byte value expressed as hex, with four hyphens thrown in to break up the monotony. That's 36 characters right there... starting with "comment=" adds another 8 characters. 44 characters total.
According to that, a comment ID can NEVER WORK, including the samples they show in their docs.
Are you just trying it on the command line, or have you tried via a web browser too? I wonder if that makes a difference. If not, we're looking at a feature that CANNOT WORK. EVER... and probably never has.
Related
Surprised I can't find a definitive answer about this anywhere online: I am setting up a translated HTML page in French with a different contact number that begins with "+33 (0)." Since I can't personally test it on this number -- a canonical question: can I get away with an anchor tag that begins <a href="tel:+33(0)..." i.e. has a number contained in parentheses with the remaining numbers following and have the link work?
Good question. Finding a clear, authorative answer regarding href="tel:" specifically is difficult.
RFC 3986 (Section 2.2) defines parenthesis as "reserved sub-delims". This means that they may have special meaning when used in certain parts of the URL. The RFC says:
URI producing applications should percent-encode data octets that
correspond to characters in the reserved set unless these characters
are specifically allowed by the URI scheme to represent data in that
component. If a reserved character is found in a URI component and
no delimiting role is known for that character, then it must be
interpreted as representing the data octet corresponding to that
character's encoding in US-ASCII.
(Emphasis mine)
Basically, you can use any character in the US-ASCII character set in a URL. But, in some situations, parentheses are reserved for specific uses, and in those cases, they should be percent-encoded. Otherwise they can be left as is.
So, yes, you can use parentheses in href="tel:" links and they should work across all browsers. But as with any web standard in the real world, performance relies on each browser correctly implementing that standard.
However, regarding your example (<a href="tel:+33(0)...), I would steer clear of the format you have given, that is:
[country code]([substituted leading 0 for domestic callers])[area code][phone number]
While I was unable to find a definitive guide to how browsers handle such cases, I think you will find, as #DigitalJedi has pointed out, that some (perhaps all?) browsers will strip the parentheses and leave the number contained therein, ultimately resulting in an incorrect number, e.g.
+33 (0) 123 456 7890
...which may result in a call to +3301234567890.
Will this still work? Maybe? We're getting into phone number routing territory now.
Some browsers/devices may be smart enought to figure out what is intended and adapt accordingly, but I would play it safe and instead simply use:
[country code][area code][phone number], e.g.
+33 123 456 7890
or
(0) 123 456 7890
There is no downside (that I know of) to having your local users dialing the international country code - it will result in the same thing as if they had omitted it and substituted the leading zero.
As a side note, according to the ITU's (International Telecommunications Union) E.123 document, section 7.2,
The ( ) should not be used in an international number.
This recommendation concerns how phone numbers are written, but is of some relevance in terms of the text that should be used when creating an href="tel:" link, and is the reason for the two alternative examples I have provided above.
(Credit to #NiKiZe for this semi-related info).
Finally, here is some semi-related, useful information regarding browser treatment of telephone links: https://css-tricks.com/the-current-state-of-telephone-links/
The () in the href attribute should not be a problem: (href-wise)
http://example.com/test(1).html
HOWEVER, if I do a href="tel:+000 (1) 000 000", after clicking the link on phone, the dial on my phone will show +0001000000 This is tested and confirmed on a Android device
This means that the parentheses are removed, as well as the spaces.
But this could still vary because of different OS on the phone.
P.S.:
If you think the + in your number is an issue... I did test this too, and the + does not have any unexpected behavior.
MORE: href="tel:" and mobile numbers
According to ITU-T E.123 Section 7.2 Use of parentheses
The ( ) should not be used in an international number.
So (0) should not be included at all.
I read and remember the correct format should be:
+33.1 23 45 67 89
But I can't find where from.
I have a formatted CSV file for <loadData .../> of Liquibase.
There are some whitespaces for having a nice look.
But because of that whitespaces, I have wrong data in my DB.
How to solve it? Is there any "flag" or something for forcing Liquibase to trim whitespaces?
I tried to make it looking something like the next
id;name ;surname
1 ;test123;test123
2 ;test1 ;test123
3 ;"test" ;test123
Anyway, my DB contains test1__ and test"_ as well where _ is a space.
Also quotchar=""" didn't help (and it was expected, it is a redundant line).
Btw, id column which is defined as numeric - ok (1,2,3, etc with no errors).
Check out this Jira issue.
To quote Nathan Voxland:
It probably makes sense to keep the default as trimming since I think
that will cause less surprises. However, I added a global
configuration flag that lets you change the default.
You can set it either through a liquibase.trimCsvWhitespace=false
system property or by using the
LiquibaseConfiguration.getInstance().getProperty(GlobalConfiguration.class,
GlobalConfiguration.CSV_TRIM_WHITESPACE).setValue() API call.
Try adding liquibase.trimCsvWhitespace=falseproperty.
On further review, it looks like it was a change just in 3.5.0. I
usually try to keep backwards compatibility, even when it is
unexpected behavior but was thinking it had changed with 3.4.0 and so
changing it back to preserving whitespace would break other people
that are now expecting it to be trimming.
However, since it did change unexpectedly in 3.5.0 only, it is
definitely a bug and so I'm just setting the logic back to preserving
whitespace.
Accodring to Jira ticket this bug was fixed in liquibase version 3.5.1, but looks like it actually wasn't.
I am using PhpStorm and tried yesterday to use the built-in server functionality that it provides.
It works, but I find the console showing in bright red the 200 responses quite annoying, as it makes quite hard to spot real issues.
In the picture below you'll see what I mean.
Is there any way to disable these and only show for instance warnings (maybe in yellow) and errors (maybe in red)?
Use Grep Console plugin for this -- should do the job fine (does so in similar consoles).
Based on your requirements it allows you to:
change color for the matching text (or whole line if desired) based on presence of some marker (matching text)
or even hide (filter out) such line completely.
Your marker here could be [200]: for successful responses -- this is a simple "match the exact text" pattern. If it does not work (e.g. because this text is in the middle of the string .. or because it looks like regex (as [] have special meaning in regex)) then just convert it into proper regex: .*\[200\]:.* -- something like that should do.
Example of how it works:
The rule for that is highlighted (plain string as it's a very simple rule -- match exact string):
We just upgraded from opengrok-0.11.1 to opengrok-1.0 to allow access to the history and annotations etc.
However many search strings now need quoted. We used to be able to search for a file path containing unquoted hosts.txt which now finds hundreds of matches vs a quoted search for "hosts.txt" which finds the expected two files. Is there some default we can tweek to change the analyzers being used for different fields. Is this a bug?
According to the OpenGrok help (OpenGrok > Help):
if you want just exact path, enclose it in "", e.g. "src/mypath",
otherwise dividers will be removed and you get more hits
This change happened on 24-Oct-13 due to Lucene changes according to the issue 672 (where you can find more info about).
I $P(GIH,,24)= S $P(GIH,,24)="C" S
What is the meaning of two S's in above MUMPS statement?
Let me start out by saying the original statement is NOT either Standard MUMPS or InterSystems Cache, or GT.M code. Even broadly guessing what was originally meant, the final S on the line isn't something you would do in MUMPS. A single S could be a SET command, but you still don't have any arguments telling what variable could be assigned, or what value should be assigned to it.
The rest of my reply is trying to figure out what it could have meant.
Your question seems to be broken by some software. either that on stackoverflow or the cut-and-paste process to put it here:
I saw:
I $P(GIH,,24)= S $P(GIH,,24)="C" S
What is the meaning of two S's in above MUMPS statement?
It is hard to figure out what you meant, since it would require hypothesizing where quotes might be and which ones could have been deleted by the transmission of the question.
First of all, let's do something we can guess is reasonable. $P is usually an abbreviation for the built-in (intrinsic) function $PIECE. an I standing alone is probably an IF command
and an S standing alone is probably a SET command. This runs into a problem with your example, because the format of a line of MUMPS code is COMMAND COMMAND-ARGUMENT.
Aside Note: I also just tried to put the text COMMAND-ARGUMENT in "angle brackets" ie: with a less-than character at the beginning of the word and a greater-than character at the end. The text COMMAND-ARGUMENT just disappeared. Which means that stackoverflow sees it as HTML markup. I notice there is a Code marker on the top of this edit window which may or may not help.
If we do the expansions to the code above, we get:
IF $PIECE(GIH,,24)= SET $PIECE(GIH,,24)="C" SET
When we expand the final S but it looks like a SET command, but without any set-argument.
Note, if this was in a Cache system, we might have an example of extra spaces allowed by Cache, which are not allowed in Standard MUMPS, ie the S may have been the right hand side of an equality operator in the IF command. This would only make sense if Cache also allowed the argument of the SET command to be in code without an actual SET command.
i.e.:
IF $PIECE(GIH,,24)=S $PIECE(GIH,,24)="C" SET
We still would have to deal with the two commas in a row for the $PIECE intrinsic function. Currently using two commas in a row to indicate a missing argument is only allowed in Programmer-written code, not when using built-in functions. So this might be a place where we can guess what you meant, or originally pasted in.
If we put in double-quotes we run into the problem that $PIECE command (which separates a string based on a delimiter) would have an quoted string of zero length given as its second argument. Which is just as erroneous as having an empty argument.
So if we hypothesize a quoted string that has angle brackets, we would get something this for your original line:
IF $PIECE(GIH,"<something>",24)="<something>" SET $PIECE(GIH,"<something>",24)="C" SET
Note: I just saw the Code marker allows use of grave accents to keep from assuming a line is HTML - which is good since grave accent is not a character used in MUMPS coding.
As has been mentioned on another reply, the SET-$PIECE-ARGUMENT form is used to change the data stored in a database at a particular delimited substring location.
So this code might be fine for guessing, but it has gone far afield of what you may or may not have done. So I'm stopping now until we get feedback that this is even close to what you wanted. As I said at the first, this is still not quite valid code.
This is pretty bizarre, but what I think is going on is:
I $P(GIH,<null>,24)=<null>
Calling $PIECE with the second argument null will replace the entire string with the value you're assigning, which, in this case, is also null. It looks like a convoluted way of clearing the value of GIH and permitting control to flow into the following SET statement. I seriously doubt that $PIECE sets the $T flag, though, which means that calling this as the condition for the IF operator probably isn't working the way you want it to.
S $P(GIH,,24)="C"
The next statement looks a lot like the first -- replace the entirety of GIH with "C".
S
I don't think the last SET is valid MUMPS.
Why this isn't written as follows is beyond me:
s GIH="C"
Hope that helps!
Maybe Intersystems Caché handles this syntax differently, but that code results in a syntax error when I try it in Caché. There may be other versions of MUMPS for which that is valid, but I don't think it is.
As other have pointed out this statement is not valid, It appears pieces are missing
But S is the SET command in Mumps
Here is what a statement like this might look like:
I $P(GIH,"^",24)="P" S $P(GIH,"^",24)="C" S UPDATEFLG=1
in this case GIH might look something like:
GIH=256^^^42^^^^Mike^^^^^^^^^^^^^^^^P^^^
which would make this evaluate to TRUE:
I $P(GIH,"^",24)="P"
so after:
S $P(GIH,"^",24)="C"
GIH will be:
GIH=256^^^42^^^^Mike^^^^^^^^^^^^^^^^C^^^
then it would set the variable UPDATEFLG=1
Hope this helps :-)