cite your reference

(took me 2 & 1/2 hrs to find the logic)

Please don't make your reviewers and maintenance engineers go hunting for the reference you eventually found. Include the URL in the source code as a comment.

Hopefully there is some correspondence between the identifiers you're using and what appears in that reference.

javadoc

There isn't any.

Please attach at least a one-sentence /** description */ to the PascalsTriangle class.

main

This is an OK local variable name.

        Scanner s1 = new Scanner(System.in);

It suggests there's a second Scanner somewhere, but there isn't. Consider using letters instead, one of {sc, scn, scnr, scanner}.

design of API

This function is well named. It's pretty clear that we shall evaluate it for side effects.

    static void print(int[] arr, int r) {

It is unclear why caller is responsible for passing in a (1, 1) tuple. Shouldn't this routine be responsible for creating arr? If there is some design rationale, write a comment describing it.

The identifier r is manifestly the wrong name. It's not like this is a local variable, so the documentation burden is much greater. You are responsible for explaining the meaning of this parameter to an engineer who is calling into this routine. Name it something like numRows.

local variables

        int size=2, t=1, n=0;
        int [] arr1=null;
        int temp1=1, temp2=1, sizeArr1=2;

The i, j are fine. Otherwise these are not terrific name choices. Imagine you have to return to this code in six months and maintain it. You will wish you were staring at more helpful names.

It's unclear why inventing the concept of sizeArr1 is even helpful; we could have just allocated a (non-null) integer array of size 2 and then relied on arr1.length.

I suspect that the concept modeled by some of these is actually i, that is, currentRowNum.

Try to use identifiers drawn from the Business Domain when feasible. Here, I was expecting to maybe see a coeff vector full of numRows binomial coefficients. Not sure if arr or arr1 is supposed to play that role.

Inventing local temp vars like temp1 and temp2 can be fine. But strive to keep the scope so small that they're self-explanatory. Here, they're set to unity, and then you're asking a maintenance engineer to keep those cryptic numbers in mind until way down below. The bigger the scope, the greater your responsibility to explain what's going on, typically via an informative name.

extract helper

            for (int k = r - i - 1; k > 0; k--) {
                System.out.print(" ");
            }

Aha! Now here is some wonderful code. It's clear what it does.

But this loop appears alongside some bigger loops, and it's a little distracting. Replacing it with a single-line System.out.print(indent(numRows - i - 1)) would be nicer. And then that helper could use StringBuilder or whatever.

murky logic

            for (int j = 0; j <= i; j++) {
                if (i == 0) { ...
                } else if (i == 1) { ...
            }
            if (i > 2) { ...

It's unclear why the first two rows should be so special. And then we encounter the general case, but oddly it is outside the loop. Consider turning that for j loop into a helper, just so you can name it, explaining what it accomplishes.

Yes, I know this is a "print" function. But I'm a little surprised it doesn't first produce an array containing a prevRow or currRow of binomial coefficients, ideally by calling a helper. With the array in hand, the print() routine could focus on its single responsibility of formatting those numbers on stdout.

loop index

                for (int g = 0; g < sizeArr1; g++) {

We strayed from i, j, ..., that's fine. But now I'm scratching my head what g might possibly stand for. Either explain it, or stick with boring index names.

Consider extracting this for loop as a tiny helper, which would give you the opportunity to name what it does.

At least with h & w we get the clue to mentally pronounce them as "height" & "width" of some diagram that appears in the cited reference.

unit tests

There aren't any, partly due to the lack of any functional helpers. A function that is focused on displaying a result, rather than returning a result object, tends to be one that isn't a great fit for unit tests.

Writing automated tests can save edit-debug cycle time. But it can also save time spent developing the larger project, by encouraging us to break big problems into smaller ones that are easy to describe to colleagues.

This code appears to achieve its design goal.

I would not be willing to delegate or accept maintenance tasks on this code in its current form.