From fe8054814433cfc5cac60e68e0bec36ecbb9a876 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Fri, 9 Oct 2026 14:28:22 +0200 Subject: [PATCH] =?UTF-8?q?website:=20the=20header=20mark=20had=20no=20whi?= =?UTF-8?q?te=20fill=20=E2=80=94=20wrong=20source=20file=20(and=20R-916=20?= =?UTF-8?q?corrected)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I used assets/logo_notext.svg for the header mark. That file is the LIGHT-BACKGROUND variant: it has SEVEN #00408d fills and ZERO #ffffff, so on the dark nav the cloud rendered as a hollow outline. The operator caught it. logo_notext_white.svg is not the answer either -- it is a white OUTLINE version, also unfilled. Rendered all four candidates side by side on the real nav background to see it rather than infer it: only logo.svg (and logo.png) carry the real artwork -- white cloud, #051343 house and servers, #008ddf swoosh. FIX: assets/logo-mark.svg, cut from logo.svg -- keep , path6 and g2; drop the five wordmark paths and the two empty elements; viewBox cropped to the mark (70 0 505 295). Vector, correct fills, no text. All 18 pages point at it; site.css cache-bust v7 -> v8. The CSS comment now says which file NOT to swap back in, and why. AND A CORRECTION THAT REMOVES AN OPERATOR TASK (R-916). That row says the project has no usable vector master because logo.svg "sets felhom.eu as live text" in 'M+ 2c'/'Vremena Grotesk', and it waits on "the machine with the fonts". MEASURED today, while cutting the mark out of that very file: - all five wordmark elements are with real d= geometry - NO element has any content; the two present are empty leftovers - the font-family strings the row cites are Inkscape METADATA left on CONVERTED paths (-inkscape-font-specification). A grep for font-family finds them and reads as live text -- the likeliest way the original diagnosis went wrong. - proof from a renderer that lacks both fonts: Chrome draws logo.svg's lettering identical to logo.png's, side by side. NOT re-tested: librsvg specifically -- DooPlex has no rsvg-convert, inkscape or cairosvg installed today, so the original librsvg/DejaVu observation could not be reproduced either way. It does not change the structural fact: there is no font left to substitute. Consequence: the 645x408 PNG is not the only faithful copy and does not cap picture size. R-916 state -> READY with "re-check before doing any work: this may need nothing from the operator at all", rather than closed on my say-so. --- documentation/backlog/OPEN-ITEMS.md | 2 +- website/404.html | 4 ++-- website/adatkezeles.html | 4 ++-- website/alkalmazasok.html | 4 ++-- website/assets/logo-mark.svg | 2 ++ website/assets/site.css | 18 +++++++++++++----- website/biztonsagimentes.html | 4 ++-- website/en/apps.html | 4 ++-- website/en/backups.html | 4 ++-- website/en/contact.html | 4 ++-- website/en/download.html | 4 ++-- website/en/faq.html | 4 ++-- website/en/index.html | 4 ++-- website/en/technology.html | 4 ++-- website/feltetelek.html | 4 ++-- website/gyik.html | 4 ++-- website/index.html | 4 ++-- website/kapcsolat.html | 4 ++-- website/letoltes.html | 4 ++-- website/szolgaltatasok-nonpublic.html | 4 ++-- website/technologiak.html | 4 ++-- 21 files changed, 52 insertions(+), 42 deletions(-) create mode 100644 website/assets/logo-mark.svg diff --git a/documentation/backlog/OPEN-ITEMS.md b/documentation/backlog/OPEN-ITEMS.md index 94152ea4..ea0034ed 100644 --- a/documentation/backlog/OPEN-ITEMS.md +++ b/documentation/backlog/OPEN-ITEMS.md @@ -271,7 +271,7 @@ stopping line that lies. | **R-89** | Business & legal | P4 | Retention as a per-customer **commercial** policy on the hub | READY (increment 2) | — | Policy object + reconciler → ep0 prune job; keep box tokens write-only | CC | | **R-794** | Business & legal | P4 | **[P3-LOW] redis 7.4 (RSALv2 / SSPL, not OSI) runs as a private cache in seven apps: dawarich, docmost, immich, nextcloud, outline, paperless-ngx, romm.** READ 2026-10-02 (`audits/licences-2026-10-02/TABLE.md`). Read as permitted (a private cache only its app uses is not Redis offered as a service — inferred). Valkey (BSD-3) or redis 8 (AGPL option) removes the question. **Needs:** a ladder step per app to valkey or redis 8, through the harness — no hurry. | **READY — rank P3-LOW; owner: CC** **Re-ranked 2026-10-03: P3→P4: the row itself says no hurry; usage read as permitted.** | — | — | CC | | **R-914** | Business & legal | P4 | **Write the Felhom Facebook Page skill from the spike's findings.** Spike 2026-10-08 (`audits/SPIKE-facebook-page-api-2026-10-08.md`): key valid, never expires; the Page (`1360018983863273`) is reached with CREATE_CONTENT/MODERATE/ANALYZE; a scheduled text post and a scheduled photo were created, read back byte-equal and deleted (removal proven). Probe `scripts/facebook/fb_probe.py`. Gap to close in the skill: a scheduled photo's publish state was not read (no `post_id` returned). **2026-10-08 (Page pictures task) — two more for the skill:** (1) **the removal proof was not a proof**: the text post's after-DELETE answer was (#10) „does not exist, cannot be loaded due to missing permission…" — that message also means a permission gap. The skill proves removal by listing the Page's scheduled posts before and after the delete (present, then absent); the operator's Planner view on 2026-10-08 showed nothing on 15 October (a different channel, by eye). (2) **pictures by API** (READ, developers.facebook.com/docs/graph-api/reference/page/picture and …/reference/page/): `POST /{page}/picture` needs the `MANAGE` task, which the robot does not have (measured task list); the cover is `POST /{page}` `cover=`, „only by the Page Admin or Page Editor with `EDIT_PROFILE`" + `business_management`. Neither names `pages_manage_metadata`. Today the pictures are uploaded by hand (`marketing/facebook/README.md`). | **READY — owner: CC** | — | Write the skill (drafts scheduled for operator review by default); read a scheduled photo back through the Page's scheduled-post listing | CC | -| **R-916** | Business & legal | P4 | **The logo has no usable vector master: `website/assets/logo.svg` sets „felhom.eu" as live text in the fonts „M+ 2c" and „Vremena Grotesk", which DooPlex does not have, so every renderer here draws other letters.** SEEN 2026-10-08 (Facebook pictures task): librsvg drew the lettering in DejaVu; `fc-match` resolves the family to DejaVu Sans. The PNG (645 x 408) is the only faithful copy, which caps every picture made from it at about that size (`marketing/facebook/README.md`). | **WAITING-ON-OPERATOR** | the machine with the fonts | In Inkscape on that machine: select the lettering → Path → Object to Path → save as `website/assets/logo-master.svg`; then `marketing/facebook/build.py` can use it. If nothing is done: the PNG stays the master; larger prints will be soft | operator | +| **R-916** | Business & legal | P4 | **The logo has no usable vector master: `website/assets/logo.svg` sets „felhom.eu" as live text in the fonts „M+ 2c" and „Vremena Grotesk", which DooPlex does not have, so every renderer here draws other letters.** SEEN 2026-10-08 (Facebook pictures task): librsvg drew the lettering in DejaVu; `fc-match` resolves the family to DejaVu Sans. The PNG (645 x 408) is the only faithful copy, which caps every picture made from it at about that size (`marketing/facebook/README.md`). **-- MEASURED 2026-10-09, and the premise is WRONG for the file as it stands today:** the lettering in `website/assets/logo.svg` is **already converted to outlines**. All five wordmark elements are `` with real `d=` geometry (`path1 path3 path5 path7 path8`), and **no `` element has any content** — the two that exist are empty leftovers. The `font-family:'M+ 2c'` / `'Vremena Grotesk'` strings that this row cites are Inkscape METADATA left behind on converted paths (`-inkscape-font-specification`), not live text; a grep for `font-family` finds them and reads as live text, which is the likeliest way the original diagnosis went wrong. **Proof from a renderer that does NOT have those fonts:** Chrome draws `logo.svg`'s „felhom.eu” identical to `logo.png`'s, side by side (2026-10-09). **NOT re-tested:** librsvg specifically — DooPlex has no `rsvg-convert`, `inkscape` or `cairosvg` installed today, so the original librsvg/DejaVu observation could not be reproduced either way. It does not change the structural fact: there is no font to substitute. **Consequence:** the 645 x 408 PNG is NOT the only faithful copy and does not cap picture size; `logo.svg` can be rendered at any size, and `website/assets/logo-mark.svg` was cut from it this day (defs + path6 + g2) to fix the website header. | **READY — re-check before doing any work: this may need nothing from the operator at all.** The row asked for an Inkscape pass on „the machine with the fonts”; the measurement above says the file is already outlined and the operator may have nothing to do | nothing — the dependency on „the machine with the fonts” appears to be void (see the measurement) | CC or operator: confirm the outlines render correctly at a large size in one renderer that is not a browser, then CLOSE this row — or, if something really is still live text, say which element. If nothing is done: an operator task sits on the list that probably does not exist | operator | | **R-917** | Business & legal | P4 | **`COPY.md` §2, the Page's longer description (867 characters), has nowhere to go: Facebook's current Pages experience has no long-description field at all.** FOUND 2026-10-08 (Page setup task, `audits/facebook-page-setup-2026-10-08/`). Looked in four places, all on the live Page as its admin: the Page's „Névjegy" tab (Rövid áttekintés / Személyes adatok / Részletek — only a 255-character „Bemutatkozás" and the pinned category), Business Suite's „Oldal módosítása" dialog (profile picture, cover, Bemutatkozás, category, phone, e-mail, address, website, social links — and nothing else), Facebook settings → „Oldal adatai" (redirects to the same Névjegy tab) and settings → „Oldal beállítása" (name, access, type, history, status, recommendation, messaging, data sharing). MEASURED by Graph with the Page token: `description`, `general_info` and `bio` all read `null`. Writing `description` by API would need `pages_manage_metadata`; the robot key's scopes are `read_insights, pages_show_list, business_management, pages_read_engagement, pages_read_user_content, pages_manage_posts, pages_manage_engagement, public_profile`, and the task's fences forbid adding a permission. So §2 is written, reviewed and unplaceable. **Options for the operator:** (a) leave §2 unused and let the 99-character intro plus the website carry it; (b) shorten §2 to ≤ 255 characters and make it the „Bemutatkozás" instead of §1 — but §1 was written for exactly that slot, so this is really „rewrite one of the two"; (c) publish §2 as the Page's first pinned post once the app is Live (R-915), which is where a long text actually gets read; (d) ask Meta support whether the field still exists for this Page type. Recommended (c) — the text reads like a post already. | **DEFERRED — operator chose (c) on 2026-10-09:** park the text and publish it as a post once posting starts. Not a defect, and not waiting on CC | nothing — **UNBLOCKED 2026-10-09**: R-915 is closed, the app is Live, so posting can start whenever the operator wants | When posting starts: publish `COPY.md` §2 (the longer description) as the first pinned post. If nothing is done: the text stays in `COPY.md` unused, which the operator has accepted | operator | | **R-919** | Business & legal | P3 | **On a phone the Facebook Page cuts the left edge of the cover: the „s” of „saját szabályaid” and the „f” of „felhom.eu” are gone.** MEASURED 2026-10-08 on the live Page in Chrome DevTools device mode, Pixel 9 (412 × 924, mobile user agent, after a reload so Facebook serves the mobile bundle): `audits/facebook-page-setup-2026-10-08/C2-phone-headline-cut-closeup.png`. The mobile Page header is **412 × 274 = 1,504:1**, so Facebook keeps our cover's full height and shows only the centre **938 px of its 1640 px width (57,2 %)** — **351 px cut from each side**. `marketing/facebook/build.py` builds to a safe area of the centre **1028 × 544** (306 px clear of each edge), which is **45 px wider per side than the phone actually shows**; the light text in `out/cover-c.png` runs from x 333 to x 997, and the left crop edge is x 351, so the first **18 px** of the text are cut. Covers A and B are built from the same safe area and will have the same edge. Two further facts this measurement establishes: **Meta's own help page is wrong about its own rendering** — it states the mobile cover is 2,4:1 where the Page header measures 1,504:1 — and the mobile profile circle is far bigger than assumed (172 px, centred, overlapping the bottom 112 px of the 274 px cover, i.e. source x 637–1030 × y 369–624 is hidden). Not re-cropped on Facebook, per the task's fence. **-- 2026-10-09, FIXED in the build:** `marketing/facebook/build.py` now takes the phone view from the measurement (`PHONE_HDR = (412, 274)` -> the centre 938 px), so SAFE is (391, 40)-(1249, 584) and the phone profile circle is the measured CENTRED box (637, 369, 393) rather than a left-anchored one. Every cover is drawn in a derived `BAND` (408, 48)-(1249, 340), and a `cap` check holds each headline's capital at >= 4 % of the cover height. The red-proof runs on EVERY build (`control_old_window`): it draws the headline where the old 640 x 360 assumption put it, x 328, and the check must reject it -- the phone's crop edge is x 351, so 23 px were cut. Against the three covers as committed at `a76207945e` the new check convicted 3 of 3 (A 23/22 px over the left/right edges, B 63/58 px plus 1017 content pixels under the phone circle, C 63/82 px plus 1778). The profile pictures are untouched -- sha256 identical before and after. **-- 2026-10-09 (operator refinements, same day):** the profile picture now carries the logo MARK only (the lettering was unreadable at 176 px; the mark grew 69 % -> 76 % of the circle, canvas 932 -> 648), and the covers set the headline the way `site.css` sets `.page-index .hero-text h1` (Bold 700, letter-spacing -0.03em, not ExtraBold 800 untracked) with „felhom.eu” drawn from the logo's OWN lettering instead of typed. No geometry changed; every R-919 check and the red-proof stand. **-- 2026-10-09 (second measurement):** a phone has TWO views and they disagree. SIGNED IN the sides are cut (confirmed on the operator's REAL phone, Chrome/Android: the window solves to x 351..1298 against the emulator's 351..1289 - the left edge to the pixel). SIGNED OUT the FULL width is shown but the cover is top-anchored and only the top 525 px survives (the bottom 99 px is cut; the file's blue top rule is still visible, which is how the side was established), with a much bigger, higher circle at x 486..1150 from y 232. `build.py` now carries both views, models the circles as DISCS rather than rectangles running to the bottom, and splits the artwork into a READ layer (must survive every view) and a DECOR layer (may be cropped or covered; the build reports the cost - B 39 %, C 62 %). The two-view geometry convicted all three then-current covers before the redraw (A 908 px under a circle, B 1715, C 1962). Covers redrawn: C is the operator's laptop idea with the dashboard at 640 px (was 370), B's motif grown to match. **-- 2026-10-09 (the APP measured):** the operator checked the live Page in Facebook Lite and in Chrome on his phone. Solved against the laptop frame, both give a visible window of x 349..1290 / 349..1291 - the LITE APP CROPS EXACTLY LIKE SIGNED-IN MOBILE WEB, and both agree with the emulator's 351..1289. Their circle is at x 645..1021 from y 451, LOWER than the emulator's 369, so that figure was pessimistic rather than wrong. Five views measured; the signed-out one stays the binding constraint. Cover C redrawn to the operator's layout (wordmark 88 px on top, gap, catchphrase) - one line, not his two, because two measured 392 text pixels behind the signed-out circle („saját szabályaid” read „saját szab”) and sizing them to fit drops the capital to the 25 px floor. | **VERIFY -- rebuilt on `main` 2026-10-09. The app IS now measured and the cover renders correctly there; what is left is the operator's look at the NEW cover in the app after uploading it.** | — | Operator: upload the rebuilt cover-c (and the profile picture if not already), then confirm in the Facebook app that the wordmark and the catchphrase are whole. Close on that word | CC | | **R-920** | Business & legal | P4 | **The Messenger „Gyakori kérdések" automation does not exist for this Page, so `COPY.md` §5 — four questions with answers condensed from `gyik.html` — has nowhere to go.** FOUND 2026-10-09 (Page details task, `audits/facebook-page-details-2026-10-09/`). SEARCHED, not assumed absent: the create-automation catalogue („Az összes automatizálás") holds exactly THREE templates — Automatikus válasz, Távolléti üzenet, A megválaszolatlan üzenetek azonosítása (`B5-no-faq-template-all-three.jpg`); the template search for „kérdés" answers **„Nincs a keresésnek megfelelő automatizálási sablon."** while the POSITIVE CONTROL „üzenet" returns two, so the search works and the term genuinely misses; the existing instant-reply automation carries only channel, message and media — no FAQ and no quick replies; and the business-portfolio settings have no messaging/FAQ entry. The copy is written, sourced line by line to `gyik.html` and committed as `marketing/facebook/COPY.md` §5, ready to paste unchanged the day the feature appears. **Same shape as R-917** (§2 has nowhere to go), and the same cause: Meta removed a Page field this project had planned copy for. **Options for the operator:** (a) leave §5 unused until Meta brings the feature back; (b) fold the four answers into the Messenger welcome message (§3) — it holds 500 characters and today uses 120, so one or two would fit, not four; (c) publish them as a pinned FAQ post once the app is Live (R-915); (d) ask Meta support whether the FAQ automation still exists for this Page type. Recommended (a) with (c) later — the welcome message stays short, and the website's own `gyik.html` already answers these. | **DEFERRED — operator chose (c) on 2026-10-09:** park the text and publish it as a post once posting starts. Not a defect, and not waiting on CC | nothing — **UNBLOCKED 2026-10-09**: R-915 is closed, the app is Live, so posting can start whenever the operator wants | When posting starts: publish `COPY.md` §5 (the four Messenger FAQ answers) as one later post. If nothing is done: the text stays in `COPY.md` unused, which the operator has accepted | operator | diff --git a/website/404.html b/website/404.html index 621a1c4f..d1cf98f1 100644 --- a/website/404.html +++ b/website/404.html @@ -6,7 +6,7 @@ Az oldal nem található | Felhom.eu - + @@ -14,7 +14,7 @@