Your school's admit card. Your school's design. Logo, header, photo, schedule, footer, signature — every element configurable.

How most Indian schools design their exam admit cards today

It is the Tuesday before the Class 10 pre-board in a CBSE school in Coimbatore. The exam coordinator opens the file admit_card_2025.docx from last year's drive folder and starts editing. The school logo at the top is half a centimetre too far left because the previous coordinator dragged it when she was preparing the dispatch. The school name still reads the old name from the year before the rebrand. The signature line says 'Mr. Ramachandran, Principal' but Mr. Ramachandran retired in May. The footer's note about the dress code is for last year's pre-board pattern, not the new CBSE circular. Half an hour into editing she realises the schedule table has the old subject codes; the new IT/AI elective is missing entirely.

The cost is not just the Tuesday afternoon. The Word file becomes the master template for every admit card the school issues for the next two years. Every mistake — the misaligned logo, the retired principal's name, the wrong dress code — propagates onto 1,200 admit cards across three exams before someone catches one. Parents notice. Trustees notice. The school's reputation, again, takes a small but real hit. The next coordinator, two years later, opens the same file and inherits all of last year's mistakes. The cycle repeats.

Inkwelly's Examinations module solves this by treating the admit card layout as structured configuration, not a Word file. The school designs the layout once — logo, header, photo placement, schedule columns, footer, signature — from a form with a live preview. Every admit card generated from this exam uses the configured layout. When something changes (a new principal, a rebrand, a new dress code), the school updates the form once and regenerates the affected admit cards. The Word file is gone; the configuration is the source of truth.

How admit card setting works in Inkwelly

The Admit Card Setting screen is a form-based single page with a live preview pane. The form is on the right; the preview on the left. As the coordinator changes a value in the form, the preview re-renders within milliseconds with the new value. The preview shows a real student's data (the first student in Class 10 A by default; selectable from a picker) so the layout is judged against actual content, not a Lorem-ipsum placeholder.

The form is divided into seven sections. First, the header — school logo upload (max 1 MB, recommended 800×240 pixels), school-name override (default reads from the school's master record), board affiliation tag, exam name. Second, the student information block — photo placement (top-right, top-left, center), photo size (small, medium, large), the data fields shown (name, roll number, class and section, parent name, contact number, date of birth) and the order. Third, the schedule table — columns visible (subject, component, date, day of week, time slot, duration, room, building), column order, header style (bold, underlined). Fourth, the QR code — placement (top-right, bottom-right), size, label text. Fifth, the footer text (rich-text editor with markdown support, supports bullet lists for instructions like 'arrive 30 minutes before the paper'). Sixth, the signature lines — number (1, 2 or 3), labels (e.g., 'Principal', 'Class Teacher', 'Exam Coordinator'). Seventh, language settings — primary script (English), secondary script (Hindi, Tamil, Marathi, Bengali, Kannada) for bilingual rendering of student name and school name.

Every field on the form has a sensible default that schools can use as-is. A school running their first admit card in Inkwelly can save the form with all defaults, and the generated card will look professional, with the correct school logo, photo placement, schedule, principal name and verification QR. The customisation comes in over time — the school adds the principal's signature image after the first run, the school adds a regional-language secondary script after a parent request, the school changes the footer text when the CBSE circular changes. Every change is captured in the audit log with the user, timestamp and the prior versus new value.

When the form is saved, the configuration is stored against the exam ID. All admit cards generated under that exam use the configured layout. The Admit Cards generation engine reads the layout configuration at generation time and renders the PDF accordingly. Changing the layout after admit cards have been generated requires a regeneration step — Inkwelly does not silently re-render existing cards. The coordinator clicks 'Regenerate all', the system invalidates existing cards, generates new ones with new admit-card numbers and new QR tokens, and pushes parent-app notifications.

See the layout designer in action

“Pichli baar admit card pe pichle Principal sir ka naam tha. Inkwelly ke naye admit card setting form mein ek baar update kiya, sab cards ek saath regenerate ho gaye. Word file ki samasya hi nahi rahi.”

Real-world scenarios for admit card setting

1. A new principal joins mid-session. The retired principal's name is on the school's default admit card layout. The new principal joins on Monday. The office opens the Admit Card Setting form, updates the principal name and signature image, clicks Save. The next exam's admit cards generate with the new name. The audit log captures the change with timestamp.

2. A rebrand of the school's name. The school changes its registered name from 'St. Mary's High School' to 'St. Mary's International School' after a board affiliation change. The office uploads the new logo, updates the school name, clicks 'Regenerate all admit cards'. The 412 admit cards are issued afresh with new names and tokens; parents receive notifications.

3. A regional script added for a Hindi-medium section. The school opens a Hindi-medium section for Class 1-3 in addition to the existing English-medium sections. The Hindi-medium parents request bilingual admit cards. The office enables the bilingual rendering toggle in the form, the preview shows the change, the regenerate action issues new cards. The English-medium section's cards remain English-only.

4. A specific instruction for the dress code on pre-board day. The school decides to require formal school uniform (no PE shoes, no team jerseys) for the Class 10 pre-board. The office adds a footer paragraph with the dress code under the form's footer rich-text section. The preview shows the new footer; the cards regenerate with it. The footer wraps to two lines on the smallest paper sizes.

5. A custom QR placement for a tighter card layout. The default QR position is top-right but a particular school's logo is so wide that the QR overlaps. The coordinator changes the QR placement to bottom-right via the configuration form, the preview updates, the cards generate with the QR at the bottom. The size of the QR is increased to match the new placement.

See the admit card layout designer running on your school's brand

Bring your school logo, your principal's signature image and your last year's admit card. We will configure the layout in 10 minutes and show you the new admit card live.

Limits, safety and the small print

The admit card layout configuration is per-exam by default. The 'Save as Default' option creates a school-wide default that new exams inherit. Per-exam overrides remain editable independently of the default. Changing the default does not silently update existing exams — each exam's configuration is its own row, and the regeneration of admit cards is an explicit action.

The rich-text footer accepts a constrained subset of markdown — bold, italic, bullet lists, line breaks, but no inline images, no HTML, no script tags. The constraint is a security choice; arbitrary HTML on a printed admit card is a vector for injection attacks. The footer is rendered server-side on PDF generation, with the markdown sanitised before render. Footer length is capped at 800 characters to prevent unbounded card sizes.

The logo upload is constrained to 1 MB and to PNG, JPEG or SVG. Larger files are rejected at upload time with a specific error. The uploader stores the file in Cloudflare R2 with a content-hashed URL; cache invalidation is automatic. Logos uploaded by one school are isolated to that school's tenant; cross-school logo access is blocked at the API layer. Logos that contain executable content (SVG with embedded scripts) are sanitised before storage; only static graphics elements survive.