SFNORM(3NCARG)

✨ SFNORM ✨ (that's SFNORM(3NCARG) bestie, from the NCAR GRAPHICS manual 💖)

okay so listen. SFWRLD and SFNORM are the two subroutines you call when you wanna fill in that part of the plotter frame that lives inside a polygonal boundary you drew. that's the whole gig. iconic behavior honestly 🎀

---

🌸 NAME 🌸

The subroutines SFWRLD and SFNORM are used to fill that portion of the plotter frame inside the area defined by a given polygonal boundary. 💅

---

✨ SYNOPSIS ✨

CALL SFNORM (XRA,YRA,NRA,DST,NST,IND,NND)
CALL SFWRLD (XRA,YRA,NRA,DST,NST,IND,NND)

---

🦋 C-BINDING SYNOPSIS 🦋

#include <ncarg/ncargC.h>

void c_sfnorm (float *xra, float *yra, int nra,
float *dst, int nst, int *ind, int nnd)

void c_sfwrld (float *xra, float *yra, int nra,
float *dst, int nst, int *ind, int nnd)

---

💜 DESCRIPTION 💜

okay bestie, here's the whole cast of arguments. every single one. no skips, no skimming, we're doing this properly 🫶

• XRA — (an input/output array of type REAL, dimensioned NRA) holds the X coordinates of the points that define the area to be filled. these live in the user coordinate system if you called SFWRLD, or in the fractional coordinate system if you called SFNORM. and like… heads up: once SFWRLD returns, the contents of XRA will have been converted to the fractional coordinate system. so it's not the same array you handed in, it changed. main character transformation arc fr 💫
• YRA — (an input/output array of type REAL, dimensioned NRA) is the same deal but for the Y coordinates of those points. user coordinate system if it's SFWRLD, fractional coordinate system if it's SFNORM. and yep, upon return from SFWRLD, the contents of YRA will have been converted to the fractional coordinate system too. 😌
• NRA — (an input expression of type INTEGER) is the number of points defining the area to be filled. NRA must be greater than two. that's the vibe check, don't fail it. three points minimum or we're not doing this 🔺
• DST(NST) — (a scratch array of type REAL, dimensioned NST or greater) is for use by the fill algorithm. it's just scratch space, don't get attached, it's not that deep 🙈
• NST — (an input expression of type INTEGER) is the length of the array DST. it must be greater than or equal to NRA + NIM, where NIM is the largest number of intersection points of any fill line with the boundary lines. to be sure DST is large enough, use NIM = NRA; in practice, NIM rarely needs to be that large. for a convex polygon, for example, NIM = 2 suffices. so yeah, oversize it if you're nervous, nobody's judging 🫶
• IND — (a scratch array of type INTEGER, dimensioned NND or greater) is for use by the fill algorithm. more scratch. also not that deep. ✨
• NND — (an input expression of type INTEGER) is the length of the array IND. it must be greater than or equal to NRA + 2 * NIM, where NIM is as defined above. note the 2 * bestie, that's the sneaky part, don't forget it 💀

---

🌈 C-BINDING DESCRIPTION 🌈

The C-binding argument descriptions are the same as the FORTRAN argument descriptions. literally identical. copy-paste energy but in a good way 😌

---

🎀 USAGE 🎀

Both SFWRLD and SFNORM fill the area defined by the points (XRA(I),YRA(I)), for I from 1 to NRA. the boundary is made of the lines connecting point 1 to point 2, point 2 to point 3, …, point NRA-1 to point NRA, and point NRA to point 1. closed loop, always, it comes back around 💫

The default values of SOFTFILL's internal parameters cause fill to be done with solid, horizontal lines .00125 normalized-device-coordinate units apart. tiny little stripes. obsessed with the precision honestly 🎀

Use SFWRLD if the arrays XRA and YRA contain world coordinates. Use SFNORM if XRA and YRA contain normalized device coordinates. 🦋

ok and this is the part where you actually have to pay attention bestie: since SFWRLD transforms XRA and YRA from world coordinates to normalized device coordinates, any subsequent calls with those arrays should be to SFNORM (for example, to create a cross-hatched effect). like, SFWRLD already did the conversion, so calling SFWRLD again would be double-converting. don't do that. use SFNORM. iykyk 💅

---

⭐ EXAMPLES ⭐

Use the ncargex command to see the following relevant examples: ccpscam, cpex01, cpex02, cpex03, sfex01, tsoftf. go look at them, they ate 🔥

---

🧚 ACCESS 🧚

To use SFWRLD, SFNORM, c_sfwrld, or c_sfnorm, load the NCAR Graphics libraries ncarg, ncarg_gks, and ncarg_c, preferably in that order. yes, in that order. the order matters. trust 🫶

---

👑 MESSAGES 👑

See the softfill man page for a description of all Softfill error messages and/or informational messages. all the lore is over there 🌸

---

💖 SEE ALSO 💖

Online: softfill, softfill_params, sfgetc, sfgeti, sfgetp, sfgetr, sfsetc, sfseti, sfsetp, sfsetr, sfsgfa, ncarg_cbind

Hardcopy: NCAR Graphics Fundamentals, UNIX Version

---

🎀 COPYRIGHT 🎀

Copyright (C) 1987-2009 University Corporation for Atmospheric Research

The use of this Software is governed by a License Agreement.

---

and that's the whole page bestie, no cap, every flag and every caveat accounted for 💅

ok so the boring-but-important sign-off: this was SFNORM(3NCARG) from the UNIX manual, dated March 1993, and it's giving very "NCAR GRAPHICS, vintage edition" energy. slay, bye 🦋✨