@jv2007
If you want to use @font-face, you can use like this;
@font-face {
font-family: 'korean';
src: url('./notosans.ttf') format('truetype');
unicode-range: U+AC00-FFDD;
}
@font-face {
font-family: 'english';
src: url('./opensanscondensed.ttf') format('truetype');
}
div.test {
font-family: 'korean', 'english';
}
@jv2007
But, more simple way is; just use this;
body {
font-family: 'Open Sans Condensed', 'Noto Sans KR';
}
Open Sans Condensed font doesn’t have any Korean characters, so when the renderer meet Korean chars, the second fallback Noto Sans KR would be applied instead of Open Sans Condensed.
@jv2007
Option 1 is almost right, but each font-face needs to have a different name.
Option 2 or 3 seems something related to lang attribute. If your content has explicit lang attribute on the element, it might be work, but, as far as I understand, that might not be your thing.
@BKeyport
MMM-NotificationTrigger for that purpose.
@Spinster said in Show calendar based on IP Address accessed:
Modified the calendars to suite mine. I could see even if there is no calendar defined for a particular ip. Please advice
in the calendar config, I added clientMap.
{
module: "calendar",
header: "US Holidays",
position: "top_left",
config: {
clientMap: {
"192.168.178.63": [ "cal1", "cal2", "cal3" ],
"192.168.178.22": [ "cal3", "cal4", "cal5" ]
},
calendars: [
{
url: "...",
name: "cal1",
},
...
@sdetweil
Still I can’t catch you.
[2024-05-07 15:03:33.741] [LOG] Use existing calendarfetcher for url: https://ics.calendarlabs.com/76/mm3137/US_Holidays.ics
The log shows, duplicated URL would be integrated into existing fetcher, So unlike your words, 3 clients doesn’t make 3 duplicated wasted fetcher.
If clientA needs cal1, cal2, cal3 and clientB needs cal1, cal4, cal5. In this case server should fetch 5 calendars anyway. User may need cal1 ~ cal5 even on 1 screen or 2 screens, ther server’s burden would be the same.
The only aspect that could be considered a waste is the transmission of unusing event data for cal4 and cal5 to clientA, but unless it’s a performance issue with the data parsing algorithm, simply having large data size being transmitted isn’t particularly problematic. Moreover, since the data is dropped in my code as soon as the notification is received, it can’t be deemed a significant memory issue. If the data size itself becomes problematic, it implies there’s already a problem with the original calendar module using cal1, cal2, cal3, cal4, and cal5.
Too skeptic.
@sdetweil said in Show calendar based on IP Address accessed:
@MMRIZE said in Show calendar based on IP Address accessed:
(You don’t have to modify the original source code for future-proof.)
BUT you are fetching cal for system not going to use it… SOME cals are 1000’s of entries especially old
that have to be processed… this is a bad waste of resources…and this exposes a cal problem, as if u fetch http://xyz on client 1 and client 2 and client 3, we fetch it 3 times. also bad
this could also lead to different clients showing different data between fetchIntervals…
Well, if that is the issue, we need a new “calendar” module that can ignore duplicated feed on addCalendar.
Regardless of my code, the original calendar module will fetch a same feed multiply on multi clients. It’s MM’s limitation.
@sdetweil said in Show calendar based on IP Address accessed:
BUT you are fetching cal for system not going to use it… SOME cals are 1000’s of entries especially old
that have to be processed… this is a bad waste of resources…
I Can’t understand your point.
My code is just small injection that does filtering out calendars by condition on socketNotificationReceived. No additional fetching is needed.
@Spinster
With getip of @sdetweil and MMM-ModuleMonkeyPatch, I did it. (You don’t have to modify the original source code for future-proof.)
Example.
Server is running on 192.168.178.63 and I run 2 clients on 192.168.178.22 and 192.168.178.63.
Both 2 clients can show different set of calendars.
{
module: "MMM-ModuleMonkeyPatch",
config: {
patches: [
{
module: "calendar",
method: "socketNotificationReceived",
patch: async function (original, args) {
const [ notification, payload ] = args
if (notification === "CALENDAR_EVENTS") {
const calendarName = this.config.calendars.find((cal) => cal.url === payload?.url)?.name
const r = await fetch('http://192.168.178.63:8080/modules/getip')
const ip = JSON.parse(await r.text())?.[ 'address' ] ?? null
if (!this.config.clientMap?.[ ip ]?.includes(calendarName)) {
return original(notification, { ...payload, events: [] })
}
}
return original(notification, payload)
}
}
]
}
},
{
module: "getip",
},
{
module: "calendar",
header: "US Holidays",
position: "top_left",
config: {
clientMap: {
"192.168.178.63": [ "cal1", "cal2", "cal3" ],
"192.168.178.22": ["cal3", "cal4", "cal5"]
},
calendars: [
{
url: "...",
name: "cal1",
},
{
url: "...",
name: "cal2",
},
{
url: "...",
name: "cal3",
},
{
url: "...",
name: "cal4",
},
{
url: "...",
name: "cal5",
}
]
}
},
TO Improve
Whenever notification CALENDAR_EVENTS coming, getip is called. After first execution, to store IP on the localStorage or cookie would be better.